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 <victor_how...@cable.comcast.com> 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)" <sad...@cisco.com <mailto:sad...@cisco.com>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>> > Date: Tuesday, April 7, 2015 12:19 PM > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>> > 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 <majop...@redhat.com <mailto:majop...@redhat.com>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>> > Date: Tuesday, April 7, 2015 1:45 AM > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>> > 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 <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 >>>> >>>> <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 Miguel Angel Ajo
__________________________________________________________________________ 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
