Open Stack

Kevin,
I'm aware of the blueprint. Actually I've tried to make it work, but the
rules are not applied to the OVS bridge.
Moreover there are these limitations:
1. it considers only dscp and rate limit
2. it doesn't introduce a way to manage these policy (i.e. from the admin
side)
Anyway it's a good starting point. I hope it will be extended (not sure
whether the incubation proposal passed or not).

Giuseppe

> -----Original Message-----
> From: Kevin Benton [mailto:blak111 at gmail.com]
> Sent: 20 September 2014 01:46
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][QoS] Applying QoS as Quota
> 
> Sorry, forgot to include a link.
> https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api
> 
> On Fri, Sep 19, 2014 at 4:45 PM, Kevin Benton <blak111 at 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.carlino at 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.cossu at 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.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.opensta
> >>> ck.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.opensta
> >>> ck.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
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> 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
> >
> >
> >
> > --
> > Kevin Benton
> 
> 
> 
> --
> Kevin Benton
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev