QoS policy is not enforced when using a previously used port

[Itzik Brown]

When using a port with a QoS policy that was already used the policy is not enforced

Version
=======
CentOS 7.1 RDO Liberty
openstack-neutron-7.0.1-dev28.el7.centos.noarch
openstack-neutron-common-7.0.1-dev28.el7.centos.noarch
python-neutron-7.0.1-dev28.el7.centos.noarch
openstack-neutron-ml2-7.0.1-dev28.el7.centos.noarch
openstack-neutron-openvswitch-7.0.1-dev28.el7.centos.noarch

How to reproduce
================
1. Create a QoS policy
2. Create a QoS bandwidth rule
3. Create a port
4. Associate the port with a policy
5. Launch the instance with the above port attached
6. Verify the policy is enforced
7. Delete the instance
8. Launch an instance with the above port attached
9. Verify that the QoS policy is not enforced

[Liyingjun (liyingjun)]

If no policy change for the port, any other port update will be ignored by qos agent [1].

[1]: https://github.com/openstack/neutron/blob/master/neutron/agent/l2/extensions/qos.py#L218-L219

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

I've been testing with the latest master branch in a very similar configuration.

If you create a port and then you attach this port to an instance, the policy is applied correctly.

But, if you detach the port from the instance, the port is deleted:
> nova interface-detach <instance> <port-id>

If you list the interfaces in OVS, the port is not present:
> ovs-vsctl list Interface

Also if you list the ports in neutron, the port is not in the DB:
> neutron port-list

Please, can you tell me how to execute steps 7 and 8 and maintain the port?

Thank you in advance.

[Bhalachandra Banavalikar (bhal-banavalikar)]

I could reproduce the issue and fix it. Tested it in my local devstack setup. Will soon upload the patch for review.

Thanks,
Bhal

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/255669

[OpenStack Infra (hudson-openstack)]

Change abandoned by Doug Wiegley (<email address hidden>) on branch: master
Review: https://review.openstack.org/255669
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

[Armando Migliaccio (armando-migliaccio)]

needs a new owner.

[Bhalachandra Banavalikar (bhal-banavalikar)]

Armando,

I have already submitted a patch and waiting for review feedback. I will resubmit with "recheck".

Thanks,
Bhal

[Armando Migliaccio (armando-migliaccio)]

Hi Bhal, you have a comment from a reviewer that will have to be addressed before proceeding. Your patch is scored negatively and until you take action, a recheck is not going to yield any positive result.

Cheers,
Armando

[Armando Migliaccio (armando-migliaccio)]

Feel free to restore the patch and resubmit a new revision. The bug report will automatically assigned back to you.

[Bhalachandra Banavalikar (bhal-banavalikar)]

Armando,

Agree. But the comment from reviewer (Vikram) is to remove one of the existing tests completely and so Assaf has sought expert opinion from Miguel and Ihar before we remove the test from test suite. I am waiting for Miguel and Ihar to respond.

Thanks,
Bhal

[Miguel Angel Ajo (mangelajo)]

Bhal, can you link the patch to this bug?, as per comment #2 this bug seems Incomplete/Incorrect to me. But I guess, that if there is a patch, it's not that incorrect.

Can you please reference this bug number from your patch so they are linked?

[Miguel Angel Ajo (mangelajo)]

Sorry, I didn't see the link last time, reviewing now.

[Miguel Angel Ajo (mangelajo)]

I responded on the patch,

I would like to understand why is this happening, withouth understanding it, the patch seems like a workaround.

Is the port being deleted when you shut down the instance?, is it not?.

If it's being deleted, the delete_port->_process_reset_port->policy_map.clean_by_port should make this condition to not happen... and L221> to execute. Otherwise that path has a bug to fix.

If it's not being deleted, what's removing the policy details from the port itself?, libvirt?, ovs?

Cheers, and please ping me on irc (ajo) if you need help with this one.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/317655

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/317655
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=bc47fe97d3bf6322facca58f0f1b8081c386ffe9
Submitter: Jenkins
Branch: master

commit bc47fe97d3bf6322facca58f0f1b8081c386ffe9
Author: Ilya Chukhnakov <email address hidden>
Date: Tue May 17 19:54:29 2016 +0300

    Call ext_manager.delete_port on port removal

    This patch updates OVSNeutronAgent to call ext_manager.delete_port
    when the port is removed (similar to how CommonAgentLoop does).

    Otherwise the QoS PortPolicyMap is not properly updated on port
    removal and QoS extension will not apply policies if that port is
    later reused by a VM on the same node (unless the agent is restarted).

    Change-Id: I306c496985a550176d0ddc6eb33a4a4d351acb55
    Closes-Bug: #1515533

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/320352

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/320353

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/320352
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=a5e3f00211a061847c1a33063a9f778a406e5f90
Submitter: Jenkins
Branch: stable/mitaka

commit a5e3f00211a061847c1a33063a9f778a406e5f90
Author: Sławek Kapłoński <email address hidden>
Date: Fri Apr 1 22:00:41 2016 +0000

    Improve handle port_update and port_delete events in ovs qos agent

    This patch improves getting vif port name from port info in Openvswitch QoS
    extension driver. It will prevent to have tracebacks with info that NoneType
    object has no attribute. Such situation could happen if extension driver handled
    event on port which was already deleted

    Change-Id: Ib76630183f1091436f1cd282a91cbce5fb151716
    Closes-Bug: #1536540
    Related-Bug: #1515533
    (cherry picked from commit 213d48df014eebdc96a70a9369ffc9701f419f9f)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/320353
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=7d2fc6d489c7b1844f86eebd5fb6ed489ed72f1d
Submitter: Jenkins
Branch: stable/mitaka

commit 7d2fc6d489c7b1844f86eebd5fb6ed489ed72f1d
Author: Ilya Chukhnakov <email address hidden>
Date: Tue May 17 19:54:29 2016 +0300

    Call ext_manager.delete_port on port removal

    This patch updates OVSNeutronAgent to call ext_manager.delete_port
    when the port is removed (similar to how CommonAgentLoop does).

    Otherwise the QoS PortPolicyMap is not properly updated on port
    removal and QoS extension will not apply policies if that port is
    later reused by a VM on the same node (unless the agent is restarted).

    Change-Id: I306c496985a550176d0ddc6eb33a4a4d351acb55
    Closes-Bug: #1515533
    (cherry picked from commit bc47fe97d3bf6322facca58f0f1b8081c386ffe9)

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/neutron 9.0.0.0b1 development milestone.

[Davanum Srinivas (DIMS) (dims-v)]

This issue was fixed in the openstack/neutron 8.1.2 release.

[Ihar Hrachyshka (ihar-hrachyshka)]

Mitaka is already covered; for Liberty, it's probably not worth to touch the code since it was a new feature in L, and it's not unexpected it has its issues.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Kevin Benton (<email address hidden>) on branch: master
Review: https://review.openstack.org/255669
Reason: Abandoning per Nate's comments.