Open Stack

Mike,
As per QoS spec  [1], the behavior is:
``QoS policies could be applied:

   - Per network: All the ports plugged on the network where the QoS policy
   is

   applied get the policy applied to them.
   - Per port: The specific port gets the policy applied, when the port had
   any

   network policy that one is overridden.``

As David mentioned, empty policy is probably the way to deal with the case
that there is qos network policy defined, but for some reason specific port
should be kept without the policy.  There is an option to have certain port
types to be left without policy and you can define such behavior in the
plugin.
But anyway, this is not something that is reflected at the DB or Plugin
layer, and should be handled by the QoS backend driver.
[1]
https://specs.openstack.org/openstack/neutron-specs/specs/liberty/qos-api-extension.html

BR,
Irena

On Fri, Sep 2, 2016 at 11:58 AM, Shaughnessy, David <
david.shaughnessy at intel.com> wrote:

> Hi Michael.
> When you update a network with a qos_policy_id it updates all ports on
> that network too [1].
> If you want to have a port on that network without any QoS features on it
> you can make a policy with no rules attached.
> This empty policy would override the networks QoS policy when it's
> attached to a port.
> Hope that answers your question.
> Regards.
> David.
>
> [1] https://github.com/openstack/neutron/blob/master/neutron/
> plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L427-L437
>
> -----Original Message-----
> From: Michael Micucci [mailto:micucci at midokura.com]
> Sent: Friday, September 2, 2016 8:28 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Neutron][qos] Question about behavior
> expectations if network policy is set
>
>
> Hey all,
>
> Quick question: If I have a network and a port, and neither has any QOS
> policy set, and then I change the network to set the qos_policy_id, should
> this new QOS policy affect traffic on the already-created port?
> In other words, is this a network default for future ports (like with
> port_security_enabled) which would only affect ports created on this
> network from here on out (but leave already-created ports untouched)?
> Or is this a network setting which takes effect for all ports, regardless
> if they were already created or not?
>
> If the latter, the question had come up, this seems to mean that if a net
> policy is set, then there is no way a port can be set to have no policy,
> because if you unset a port's specific policy, it will fallback to the
> network policy, rather than skip policy calculations altogether.
> So, what does one do if they want all ports on a net to follow Policy X,
> EXCEPT for a single port?
>
> I would say the first question is the most important for me to understand
> the behavior, with the second question as a further clarification.
>
> Thanks a bunch!
>
> Sincerely,
>
> Michael Micucci
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> --------------------------------------------------------------
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
>
> This e-mail and any attachments may contain confidential material for the
> sole
> use of the intended recipient(s). Any review or distribution by others is
> strictly prohibited. If you are not the intended recipient, please contact
> the
> sender and delete all copies.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160902/90297823/attachment.html>