On 19 August 2014 23:15, Alan Kavanagh wrote:
> +1, I am hoping this is just a short term holding point and this will
> eventually be merged into main branch as this is a feature a lot of
> companies, us included would definitely benefit from having supported and
> many thanks to Sean for stickin
Hi
On Wed, Aug 20, 2014 at 12:12 AM, Salvatore Orlando wrote:
> In the current approach QoS support is being "hardwired" into ML2.
>
> Maybe this is not the best way of doing that, as perhaps it will end up
> requiring every mech driver which enforces VIF configuration should support
> it.
> I se
ation binding,
without reinvent these overlapped concept.
From: Salvatore Orlando [sorla...@nicira.com<mailto:sorla...@nicira.com>]
Sent: Wednesday, August 20, 2014 6:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][QoS]
einvent these overlapped concept.
>
> --
> *From:* Salvatore Orlando [sorla...@nicira.com]
> *Sent:* Wednesday, August 20, 2014 6:12 AM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][
e overlapped concept.
From: Salvatore Orlando [sorla...@nicira.com]
Sent: Wednesday, August 20, 2014 6:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][QoS] Request to be considered for
neutron-incubator
In the
In the current approach QoS support is being "hardwired" into ML2.
Maybe this is not the best way of doing that, as perhaps it will end up
requiring every mech driver which enforces VIF configuration should support
it.
I see two routes. One is a mechanism driver similar to l2-pop, and then you
mig
+1, I am hoping this is just a short term holding point and this will
eventually be merged into main branch as this is a feature a lot of companies,
us included would definitely benefit from having supported and many thanks to
Sean for sticking with this and continue to push this.
/Alan
-Or
Actually, whether the incubator is involved for not, this might be a
great candidate for implementation using an ML2 extension driver. See
https://review.openstack.org/#/c/89211/ for the code under review for
Juno, and also
https://docs.google.com/a/noironetworks.com/document/d/14T-defRnFl6M2xR
+1.
This work in particular brings up a question about the incubator. One of
the rules was that the neutron core code can't import code from the
incubated projects. The QoS requires a mixin to annotate the port and
network objects with QoS settings. How exactly would we actually use the
QoS code f
