Hi, It will overlap with the Telco Working group weekly meeting [1]. It's too bad, since Qos is a big interest for Telco Cloud Operator!
Mathieu [1]https://wiki.openstack.org/wiki/TelcoWorkingGroup#Meetings On Tue, Apr 14, 2015 at 10:43 AM, Miguel Angel Ajo Pelayo < [email protected]> wrote: > Ok, after one week, looks like the most popular time slot is B, > that is 14:00 UTC / Wednesdays. > > I’m proposing first meeting for Wednesday / Apr 22th 14:00 UTC / > #openstack-meeting-2. > > Tomorrow (Apr 15th / 14:00 UTC) It’s a been early since the announcement, > so > I will join #openstack-meeting-2 while working on the agenda for next > week, feel free to join > if you want/have time. > > > > > On 9/4/2015, at 22:43, Howard, Victor <[email protected]> > wrote: > > I prefer Timeslot B, thanks for coordinating. I would be interested in > helping out in any way with the design session let me know! > > From: "Sandhya Dasu (sadasu)" <[email protected]> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > Date: Tuesday, April 7, 2015 12:19 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting > > Hi Miguel, > Both time slots work for me. Thanks for rekindling this effort. > > Thanks, > Sandhya > > From: Miguel Ángel Ajo <[email protected]> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > Date: Tuesday, April 7, 2015 1:45 AM > To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting > > 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. > > > > > > > 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: [email protected]?subject:unsubscribe > <http://[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://[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://[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 > > > Miguel Angel Ajo > > > > > __________________________________________________________________________ > 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
