Right!  If the wiki<https://wiki.openstack.org/wiki/Neutron/QoS> is up to date, 
you can look there.  (I guess I assumed you had already checked that out since 
it's had much more exposure than port templates).  Also, you should check out 
flavors:

https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework<http://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework>

Chuck


On Sep 19, 2014, at 4:45 PM, Kevin Benton 
<blak...@gmail.com<mailto:blak...@gmail.com>> wrote:

Well there is the QoS work that has been pushed to incubation or Kilo.

On Fri, Sep 19, 2014 at 1:40 PM, Carlino, Chuck 
<chuck.carl...@hp.com<mailto:chuck.carl...@hp.com>> wrote:
I'm in HP, but not in the group that owns this effort, so I don't know what its 
status is.  There is a havana-based implementation floating around somewhere 
inside HP.  I'll ask around to see what I can find out.

I'm pretty sure there's nothing going on in the community.

Chuck

On Sep 19, 2014, at 5:28 AM, Giuseppe Cossu 
<giuseppe.co...@create-net.org<mailto:giuseppe.co...@create-net.org>> wrote:

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

Giuseppe

-----Original Message-----
From: Carlino, Chuck [mailto:chuck.carl...@hp.com<http://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@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.cossu@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

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


_______________________________________________
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