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-framework
https://blueprints.launchpad.net/neutron/+spec/neutron-port-template-policy

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.co...@create-net.org<mailto:giuseppe.co...@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_ve...@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.co...@create-net.org<mailto:giuseppe.co...@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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Kevin Benton
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to