Open Stack

Hi Miguel,
Thank you for leading this.


On Tue, Apr 7, 2015 at 8:45 AM, Miguel Ángel Ajo <majopela at redhat.com>
wrote:

> On Tuesday, 7 de April de 2015 at 3:14, Kyle Mestery wrote:
>
> 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.
>
> Yes, I’m fully aware of it, it was also a new feature, so it was out of
> scope for Kilo.
>
> 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.
>
> I quite agree here, but IMHO, as you said it’s a quite open field
> (limiting, guaranteeing,
> marking, traffic shaping..), we should do our best in trying to define a
> model allowing us
> to build that up in the future without huge changes, on the API side I
> guess micro versioning
> is going to help in the API evolution.
>
> Also, at some point, we should/could need to involve the nova folks, for
> example, to define
> port flavors that can be associated to nova
> instance flavors, providing them
> 1) different types of network port speeds/guarantees/priorities,
> 2) being able to schedule instance/ports in coordination to be able to met
> specified guarantees.
>
> yes, complexity can sky rocket fast,
>
> 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
>
> Yes, I believe we should look into the future , but at the same pick our
> very first feature (or a
> very simple set of them) for L, stick to it, and try to make a design
> that can be extended.
>
+1

>
>
>
>
>
>     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).
>
> Yes it’s something I looked at, I must admit I wasn’t able to see it work
> together (It doesn’t
> mean it doesn’t play well, but most probably I was silly enough not to
> see it :) ),
>
> I didn’t want to distract attention from the Kilo cycle focus making
> questions, so it should
> be a good thing to talk about during the first meetings.
>
> Who are the flavor fathers/mothers? ;)
>
>
>
>
> Morever, consider using "common" tools such as the specs repo to share and
> discuss design documents.
>
>
> Also a good idea.
>
> Yes, that was the plan now, we didn’t use it before to avoid creating
> unnecessary noise during this cycle.
>
>
>
>
>     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.
>
> Very interesting [1]!, nice to see we start to have a bunch of people with
> an interest in QoS.
>
>
> 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.
>
>
> Yes, a bit of preliminary discussion, and a “deadline” and final
> discussion on summit. Sounds good.
>
>
> We'd need to fill in page [2], and find an empty slot on [3]
>
>
> [2] done, and Meetings/QoS created
>
> About [3]
> Do any of those sound reasonable:
> a) Thursdays / 19:00 CEST
> b)  Wednesdays / 16:00 CEST
>
> Both times work for me. Maybe it worth to use surveymonkey schedule poll
to choose time that works the best for majority?

> 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.
>
>
> Correct, that seems a natural thing to do once the meetings can be done
> under a certain
> amount of time we could move them to a weekly meeting timeslot for
> details/progress tracking.
>
>
>
> Thanks for starting this thread!
>
> Thank you all :)
>
>
> [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
>
>
> __________________________________________________________________________
> 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/20150407/774a159d/attachment.html>