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:blak...@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 <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> > 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> > 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] > >>>> 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.opensta > >>> ck.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.opensta > >>> ck.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 > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > -- > > Kevin Benton > > > > -- > Kevin Benton > > _______________________________________________ > 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