Ok,
1) #openstack-meeting-2 doesn’t exist (-alt is it)
2) and not only that we’re colliding the TWG meeting,
but all the meeting rooms starting at UTC 14:30 are busy.
3) If we move -30m (UTC 13:30) then we could use meeting room
#openstack-meeting-3
before the neutron drivers meeting, and removing some overlap
with the TGW meeting.
But I know it’s an awful time (yet more) for anyone in the USA west coast.
What do you think?
#openstack-meeting-3 @ UTC 13:30 sounds good for everybody, or should we
propose some
other timeslot?
What a wonderful meeting organizer I am… :/
Best,
Miguel Ángel?
Unless we’re able to live with 30min, we may need to move the meeting
> On 15/4/2015, at 15:26, Veiga, Anthony <[email protected]>
> wrote:
>
> Miguel,
> As a telco operator, who is active in the WG, I am absolutely an interested
> party for QoS. I’d be willing to hop between the two of them if absolutely
> necessary (it’s IRC, after all) but would prefer they not overlap if
> possible. Thanks!
> -Anthony
>
>> On Apr 15, 2015, at 6:39 , Miguel Angel Ajo Pelayo <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> 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 <[email protected]
>>> <mailto:[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]
>>>> <mailto:[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] <mailto:[email protected]>>
>>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>>> <[email protected]
>>>> <mailto:[email protected]>>
>>>> Date: Tuesday, April 7, 2015 12:19 PM
>>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>> <[email protected]
>>>> <mailto:[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] <mailto:[email protected]>>
>>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>>> <[email protected]
>>>> <mailto:[email protected]>>
>>>> Date: Tuesday, April 7, 2015 1:45 AM
>>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>> <[email protected]
>>>> <mailto:[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]
>>>>> <mailto:[email protected]>> wrote:
>>>>>>
>>>>>>
>>>>>> On 7 April 2015 at 00:33, Armando M. <[email protected]
>>>>>> <mailto:[email protected]>> wrote:
>>>>>>>
>>>>>>> On 6 April 2015 at 08:56, Miguel Ángel Ajo <[email protected]
>>>>>>> <mailto:[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
>>>>>>>
>>>>>>> <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:
>>>>>>>> [email protected]?subject:unsubscribe
>>>>>>>> <http://[email protected]/?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:
>>>>>>> [email protected]?subject:unsubscribe
>>>>>>> <http://[email protected]/?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:
>>>>>> [email protected]?subject:unsubscribe
>>>>>> <http://[email protected]/?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:
>>>>> [email protected]?subject:unsubscribe
>>>>> <mailto:[email protected]?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: [email protected]
>>>> <mailto:[email protected]>?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: [email protected]
>> <mailto:[email protected]>?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: [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
