[openstack-dev] [Neutron][QoS] Applying QoS as Quota

Giuseppe Cossu giuseppe.cossu at create-net.org
Fri Sep 19 12:28:03 UTC 2014


Chuck,
It seems quite interesting! Are hp or community working to implement it?

Giuseppe 

> -----Original Message-----
> From: Carlino, Chuck [mailto:chuck.carlino at hp.com]
> Sent: 19 September 2014 04:52
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][QoS] Applying QoS as Quota
> 
> When you say 'associate to VMs', that would be associating to neutron
ports,
> right?  If so, this is a subset of what is in:
> 
>
https://blueprints.launchpad.net/neutron/+spec/neutron-port-template-frame
work
>
https://blueprints.launchpad.net/neutron/+spec/neutron-port-template-polic
y
> 
> which also include things like bandwidth guarantees and security policy.
I'm
> not sure if anyone is pursuing these right now, but there may be some
useful
> ideas in there.
> 
> Chuck
> 
> 
> On Sep 18, 2014, at 4:25 PM, Giuseppe Cossu <giuseppe.cossu at create-
> net.org<mailto:giuseppe.cossu at create-net.org>> wrote:
> 
> Hello,
> I'm aware it's not so easy to define a solution, so I'll expose my idea.
> I was thinking about a "network flavor" that a tenant can associate to
VMs.
> Basically the network flavour is a QoS policy.
> The admin can define the network flavors (Gold, Silver, ... call it as
you
> want) with a set of parameters (some visible to user, some not).
> If we define this kind of flavours, a related quota should be define to
keep
> track the network resources.
> 
> Giuseppe
> 
> From: Veiga, Anthony
> [mailto:Anthony_Veiga at cable.comcast.com<http://cable.comcast.com>]
> Sent: 10 September 2014 15:11
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][QoS] Applying QoS as Quota
> 
> 
> 
> Using the quota system would be a nice option to have.
> 
> Can you clarify what you mean by cumulative bandwidth for the tenant? It
would
> be possible to rate limit at the tenant router, but having a cumulative
limit
> enforced inside of a tenant would be difficult.
> 
> On Wed, Sep 10, 2014 at 1:03 AM, Giuseppe Cossu <giuseppe.cossu at create-
> net.org<mailto:giuseppe.cossu at create-net.org>> wrote:
> 
> Hello everyone,
> 
> Looking at the QoS blueprint (proposed for incubation), I suggest to
consider
> adding some parameters to Neutron Quotas. Let's suppose using rate-limit
for
> managing QoS. The quota parameters could be such as rate_limit (per
port) and
> max_bandwidth (per tenant). In this way it is possible to set/manage QoS
> quotas from the admin side, and for instance set the maximum bandwidth
allowed
> per tenant (cumulative).
> 
> What do you think about it?
> 
> I'm cautious about this.  We'd either need to allow a "Number of DSCP
> settings" and set them outside the quota or leave it out altogether.
Let's
> not forget that there's more than just rate limiting in QoS, and we need
to
> make sure all the options are included.  Otherwise, there's going to be
a lot
> of user and operator confusion as to what is and isn't considered part
of the
> quota.
> -Anthony
> 
> Regards,
> Giuseppe
> 
> --------------------------------------------------------
> Giuseppe Cossu
> CREATE-NET
> --------------------------------------------------------
> 
> _______________________________________________
> OpenStack-dev mailing list
>
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> --
> Kevin Benton
> _______________________________________________
> OpenStack-dev mailing list
>
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list