Open Stack

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 <
mangelajo at 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_Howard at 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)" <sadasu at cisco.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Tuesday, April 7, 2015 12:19 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at 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 <majopela at redhat.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Tuesday, April 7, 2015 1:45 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at 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 <sorlando at nicira.com>
> wrote:
>
>
>
> On 7 April 2015 at 00:33, Armando M. <armamig at gmail.com> wrote:
>
>
> On 6 April 2015 at 08:56, Miguel Ángel Ajo <majopela at 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
>
>
>               [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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150415/da1bb0f0/attachment.html>