qos scenario tests failure for linuxbridge

[YAMAMOTO Takashi]

it should skip if the functionality is not supported.
it has require_qos_rule_type check but it's broken after Ia00d349625db358ab486802fc0ff2e69eaa3895e .

eg. http://logs.openstack.org/26/468326/1/check/gate-tempest-dsvm-neutron-scenario-linuxbridge-ubuntu-xenial-nv/54e3dbe/testr_results.html.gz

NOTE: the CI has both of ovs and linuxbridge MDs enabled.

Traceback (most recent call last):
  File "/opt/stack/new/neutron/neutron/tests/tempest/scenario/test_qos.py", line 168, in test_qos
    qos_policy_id=policy_id)
  File "/opt/stack/new/neutron/neutron/tests/tempest/services/network/json/network_client.py", line 154, in _update
    resp, body = self.put(uri, post_data)
  File "tempest/lib/common/rest_client.py", line 334, in put
    return self.request('PUT', url, extra_headers, headers, body, chunked)
  File "tempest/lib/common/rest_client.py", line 659, in request
    self._error_checker(resp, resp_body)
  File "tempest/lib/common/rest_client.py", line 780, in _error_checker
    raise exceptions.Conflict(resp_body, resp=resp)
tempest.lib.exceptions.Conflict: An object with that identifier already exists
Details: {u'message': u'Rule bandwidth_limit is not supported by port 6f42de3d-43ad-4d27-a523-efc0f60c0944', u'detail': u'', u'type': u'QosRuleNotSupported'}

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Hello:

I'm testing a possible solution in [1].

I think the problem is in the vif type. In https://review.openstack.org/#/c/447150/, vif_type='tap' replaces 'bridge'. The problem here is [2] keeps the previous vif type for Linux Birdge.

In [1] PS2, I'm testing if this change solves the problem.

IMO, the poblem is not in [3]. On the contrary, this patch revealed the problem.

[1] https://review.openstack.org/#/c/468326/
[2] https://github.com/openstack/neutron/blob/master/neutron/services/qos/drivers/linuxbridge/driver.py#L48
[3] https://review.openstack.org/#/c/461257/

[Slawek Kaplonski (slaweq)]

Port in this example has got binding_type = 'tap' and this is not supported by QoS drivers: http://logs.openstack.org/26/468326/1/check/gate-tempest-dsvm-neutron-scenario-linuxbridge-ubuntu-xenial-nv/54e3dbe/logs/screen-q-svc.txt.gz#_May_29_02_45_59_713483

What is this binding type? Should it be supported by Linuxbridge/Openvswitch QoS drivers maybe?

[OpenStack Infra (hudson-openstack)]

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

[YAMAMOTO Takashi (yamamoto)]

Rodolfo,

even if linuxbridge is fixed, the issue with mixed mech drivers still exists when one of them doesn't support a rule type, right?

[OpenStack Infra (hudson-openstack)]

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

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Hello Yamamoto:

> even if linuxbridge is fixed, the issue with mixed mech drivers still exists when one of them
> doesn't support a rule type, right?

Yes, that's correct. But this list should provide (and the idea was accepted) the whole list of rules accepted by all loaded drivers. This list can't be only a set of common accepted rules, because it's incomplete. So, you can create a rule which could be not supported by any of the loaded backends.

But QoS plugin is aware of this and gives you a warning message in case you try to link a backend with an incompatible rule. Also there is a patch https://review.openstack.org/#/c/466500/ which will provide more information about the supported rule types and the loaded drivers.

If you are experiencing a problem with a test, please give us the reference to this problem (logs) and we can help you migrating you out-of-tree plugin test to this new feature.

Reverting the commit https://review.openstack.org/#q,3299cdffae5cd7196a1676da103da5e2e413ec21,n,z just because some tests are failing shouldn't be the solution. Instead of that, we should try to solve the problems in the test.

[YAMAMOTO Takashi (yamamoto)]

Rodolfo,

"just because some tests are failing" is not a reason i submitted a revert.
i did so because we should maintain api compatibility.

[YAMAMOTO Takashi (yamamoto)]

i agree there are multiple issues.
i filed a separate bug for api semantics. bug 1694396

[OpenStack Infra (hudson-openstack)]

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

commit 9fbd9eb3b7b01b5503997655ae5e8729442801eb
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Mon May 29 08:54:35 2017 +0100

    Change supported vif type in Linux Bridge.

    With [1], the vif_type for a Linux Bridge port is set
    to 'tap', replacing 'bridge'. This definition needs to be
    changed in the list of supported vif types in the pluging
    driver.

    [1] https://review.openstack.org/#/c/447150/

    Change-Id: I715565627b2446533298b5905edbaa256bd84c92
    Closes-Bug: #1694190

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 11.0.0.0b2 development milestone.

[OpenStack Infra (hudson-openstack)]

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

commit 55d810c7e68dd5379a55da45f1cf43ac78573497
Author: YAMAMOTO Takashi <email address hidden>
Date: Tue May 30 03:01:26 2017 +0000

    Revert "Change list of available qos rules"

    This reverts commit 3299cdffae5cd7196a1676da103da5e2e413ec21.

    At least, there's a user which relies on the previous
    semantics. (Our tempest plugin)
    We should not change API semantics lightly
    in an incompatible way.

    Closes-Bug: #1694396
    Related-Bug: #1694190
    Change-Id: I88a216951d8996ac8bc90078b4239f0d25392e58

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/ocata
Review: https://review.openstack.org/490944

[OpenStack Infra (hudson-openstack)]

Change abandoned by Jakub Libosvar (<email address hidden>) on branch: stable/ocata
Review: https://review.openstack.org/490944
Reason: As per Rodolfo, this should not be backported