> On Apr 6, 2015, at 10:45 PM, Miguel Ángel Ajo <majop...@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 <sorla...@nicira.com >> <mailto:sorla...@nicira.com>> wrote: >> >> >> On 7 April 2015 at 00:33, Armando M. <arma...@gmail.com >> <mailto:arma...@gmail.com>> wrote: >> >> On 6 April 2015 at 08:56, Miguel Ángel Ajo <majop...@redhat.com >> <mailto:majop...@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. >> >> >>> >>> 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? ;)
The parentage is kind of like a west virginia non-branching family tree. You can find the specs here: https://review.openstack.org/#/c/168988/ <https://review.openstack.org/#/c/168988/> http://docs-draft.openstack.org/88/168988/1/check/gate-neutron-specs-docs/cf024a5//doc/build/html/ <http://docs-draft.openstack.org/88/168988/1/check/gate-neutron-specs-docs/cf024a5//doc/build/html/> Let’s sync up on IRC. Thanks, doug > >> >> 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 > >> 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 >>>> >>>> <https://openstacksummitmay2015vancouver.sched.org/event/27eeef71d5f57997ac09b4c7783c72fe#.VSMIzJT-NhM> >>>> >>> [2] https://wiki.openstack.org/wiki/NeutronSubTeams >>> <https://wiki.openstack.org/wiki/NeutronSubTeams> >>> [3] https://wiki.openstack.org/wiki/Meetings >>> <https://wiki.openstack.org/wiki/Meetings> >>> >>> >>> >>> >>> Miguel Ángel Ajo >>> >>> [1] https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api >>> <https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api> >>> [2] >>> https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing >>> >>> <https://drive.google.com/file/d/0B2XATqL7DxHFRHNjU3k1UFNYRjQ/view?usp=sharing> >>> [3] >>> https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231 >>> >>> <https://docs.google.com/document/d/1xUx0Oq-txz_qVA2eYE1kIAJlwxGCSqXHgQEEGylwlZE/edit#heading=h.2pdgqfl3a231> >>> [4] >>> https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification >>> >>> <https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
