Open Stack

On Mon, Apr 6, 2015 at 6:04 PM, Salvatore Orlando <sorlando at nicira.com>
wrote:

>
>
> On 7 April 2015 at 00:33, Armando M. <armamig at gmail.com> wrote:
>
>>
>> On 6 April 2015 at 08:56, Miguel Ángel Ajo <majopela at redhat.com> wrote:
>>
>>>  I’d like to co-organized a QoS weekly meeting with Sean M. Collins,
>>>
>>>     In the last few years, the interest for QoS support has increased,
>>> Sean has been leading
>>> this effort [1] and we believe we should get into a consensus about how
>>> to model an extension
>>> to let vendor plugins implement QoS capabilities on network ports and
>>> tenant networks, and
>>> how to extend agents, and the reference implementation & others [2]
>>>
>>
> As you surely know, so far every attempt to achieve a consensus has failed
> in a pretty miserable way.
> This mostly because "QoS" can be interpreted in a lot of different ways,
> both from the conceptual and practical perspective.
> It is important in my opinion to clearly define the goals first. For
> instance a simple extensions for bandwidth limiting could be a reasonable
> target for the Liberty release.
> Moving things such as ECN into "future works" is the right thing to do in
> my opinion. Attempting to define a flexible framework that can deal with
> advanced QoS policies specification is a laudable effort, but I am a bit
> skeptical about its feasibility.
>
> ++, I think focusing on perhaps bandwidth limiting may make a lot of sense.


>
>
>>
>>>     As per discussion we’ve had during the last few months [3], I
>>> believe we should start simple, but
>>> prepare a model allowing future extendibility, to allow for example
>>> specific traffic rules (per port,
>>> per IP, etc..), congestion notification support [4], …
>>>
>>
> "Simple" in my mind is even more extreme then what you're proposing
> here... I'd start with bare APIs for specifying bandwidth limiting, and
> then phase them out once this "framework" is in place.
> Also note that this kind of design bears some overlap with the flavor
> framework which is probably going to be another goal for Liberty.
>
> Indeed, and the flavor framework is something I'm hoping we can land by
Liberty-1 (yes, I just said Liberty-1).


> Morever, consider using "common" tools such as the specs repo to share and
> discuss design documents.
>
>
Also a good idea.


>
>>>     It’s the first time I’m trying to organize an openstack/neutron
>>> meeting, so, I don’t know what’s the
>>> best way to do it, or find the best timeslot. I guess interested people
>>> may have a saying, so I’ve
>>> looped anybody I know is interested in the CC of this mail.
>>>
>>
>> I think that's a good idea. Incidentally I was speaking with Sean
>> regarding Summit session [1], and we were hoping we could get some folks
>> together either prior or during the summit, to try and get some momentum
>> going behind this initiative, once again.
>>
>
> I think is a good idea as well.  I was thinking that perhaps it might be a
> good idea to grab a design summit session as well (surely not a fishbowl
> one as they're totally unfit for this purpose).
> However, it might be good to achieve some sort of consensus before the
> summit, as as we know fairly well now the summit is probably the worst
> place where consensus can be achieved!
>
> And finally, agreed here as well.


>
>> We'd need to fill in page [2], and find an empty slot on [3]
>>
>> One thing I had proposed to Miguel was to use the meeting as an initial
starting point, and then once momentum is achieved to naturally end it and
move any further meeting needs to the regular Neutron meeting.


> Thanks for starting this thread!
>>
>> [1]
>> https://openstacksummitmay2015vancouver.sched.org/event/27eeef71d5f57997ac09b4c7783c72fe#.VSMIzJT-NhM
>>
>> [2] https://wiki.openstack.org/wiki/NeutronSubTeams
>> [3] https://wiki.openstack.org/wiki/Meetings
>>
>>
>>
>>>
>>> Miguel Ángel Ajo
>>>
>>> [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api
>>> [2]
>>> https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing
>>> [3]
>>> https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231
>>> [4]
>>> https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150406/d2d6f4db/attachment.html>