Hi Miguel, Thank you for leading this.
On Tue, Apr 7, 2015 at 8:45 AM, Miguel Ángel Ajo <[email protected]> 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 <[email protected]> > wrote: > > > > On 7 April 2015 at 00:33, Armando M. <[email protected]> wrote: > > > On 6 April 2015 at 08:56, Miguel Ángel Ajo <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
