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? ;) > > > 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 > > > > > > [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-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 > > > > > > > > > > > > > __________________________________________________________________________ > > > 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 > > > > > > > > > __________________________________________________________________________ > > 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 > > > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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
