I saw Mathieu Rohon message on the mail list archive, but it didn’t reach my inbox for some reason:
>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 ><https://wiki.openstack.org/wiki/TelcoWorkingGroup#Meetings> My intention was to set the meeting one hour earlier, but it seems that the DST time changes got to confuse me, I’m very sorry. I’m ok with moving the meeting 1 hour later (15:00 UTC) for future meetings, as long as it still works for other people interested in the QoS topic. Mathieu, I’m not sure if people from the telco meeting would be interested in participation on this meeting, but my participation on the TWG meeting would probably help getting everyone in sync. Best, Miguel Ángel > On 14/4/2015, at 10:43, Miguel Angel Ajo Pelayo <mangel...@redhat.com> 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 <victor_how...@cable.comcast.com >> <mailto: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 >> <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> > > Miguel Angel Ajo > > > 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
