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.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 >> 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
