Open Stack

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.openstack.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.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
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Kevin Benton



-- 
Kevin Benton