Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 2027305

Summary: OpenStack command line interface behaves differently listing subnets and networks with tags
Product: Red Hat OpenStack Reporter: Eric Nothen <enothen>
Component: python-openstackclientAssignee: Rodolfo Alonso <ralonsoh>
Status: CLOSED NOTABUG QA Contact: nlevinki <nlevinki>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16.1 (Train)CC: apevec, aschultz, egarciar, jpichon, lhh, ralonsoh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-12-03 09:33:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Eric Nothen 2021-11-29 11:20:46 UTC 
Description of problem:
OpenStack command line interface behaves differently listing subnets and networks with tags.

When listing subnets and filtering by name and tag, the openstack cli shows all subnets that match the tag, despite the name, as if the client would be applying an OR to the conditions:

overcloud) [stack@ostack-pt-1-ucloud-16 ~]$ openstack subnet list --name subnet1 --network net1 --tag yulia
+--------------------------------------+---------+--------------------------------------+------------------+
| ID                                   | Name    | Network                              | Subnet           |
+--------------------------------------+---------+--------------------------------------+------------------+
| 72d33337-bd0f-4c53-99b5-fc47f05c12ef | subnet2 | e8e12fc5-190e-44ce-99b1-05e75df0d1fb | 192.168.101.0/24 |
| a4176c5b-8943-4d2b-9619-1a71c7895c32 | subnet1 | eb2c9a54-1d88-4086-9df2-e7ac1c849c32 | 192.168.100.0/24 |
+--------------------------------------+---------+--------------------------------------+------------------+

However when listing networks, the it only shows the network matching both name and tag, as if the client would be applying an AND to the conditions:

(overcloud) [stack@ostack-pt-1-ucloud-16 ~]$ openstack network list --name net1 --tag yulia
+--------------------------------------+------+--------------------------------------+
| ID                                   | Name | Subnets                              |
+--------------------------------------+------+--------------------------------------+
| eb2c9a54-1d88-4086-9df2-e7ac1c849c32 | net1 | a4176c5b-8943-4d2b-9619-1a71c7895c32 |
+--------------------------------------+------+--------------------------------------+


Version-Release number of selected component (if applicable):
(overcloud) [stack@ostack-pt-1-ucloud-16 ~]$ more /etc/rhosp-release 
Red Hat OpenStack Platform release 16.1.6 GA (Train)

How reproducible:
Could not reproduce it on a test environment. However customer and Cisco could reproduce it. Instructions below.


Steps to Reproduce:
1. Create networks with tag:
openstack network create net1 --tag yulia --project yulia
openstack network create net2 --tag yulia --project yulia
 
2. Create subnets with tag under the previously-defined networks:
openstack subnet create subnet1 --network net1 --subnet-range 192.168.100.0/24 --tag yulia --project yulia
openstack subnet create subnet2 --network net2 --subnet-range 192.168.101.0/24 --tag yulia --project yulia


Actual results:
3. List subnets matching name and tag (two are shown, one of them not matching the name):
$ openstack subnet list --name subnet1 --network net1 --tag yulia
+--------------------------------------+---------+--------------------------------------+------------------+
| ID                                   | Name    | Network                              | Subnet           |
+--------------------------------------+---------+--------------------------------------+------------------+
| 72d33337-bd0f-4c53-99b5-fc47f05c12ef | subnet2 | e8e12fc5-190e-44ce-99b1-05e75df0d1fb | 192.168.101.0/24 |
| a4176c5b-8943-4d2b-9619-1a71c7895c32 | subnet1 | eb2c9a54-1d88-4086-9df2-e7ac1c849c32 | 192.168.100.0/24 |
+--------------------------------------+---------+--------------------------------------+------------------+

4. List networks matching name and tag (only one shown, matching both name and tag):
$ openstack network list --name net1 --tag yulia
+--------------------------------------+------+--------------------------------------+
| ID                                   | Name | Subnets                              |
+--------------------------------------+------+--------------------------------------+
| eb2c9a54-1d88-4086-9df2-e7ac1c849c32 | net1 | a4176c5b-8943-4d2b-9619-1a71c7895c32 |
+--------------------------------------+------+--------------------------------------+

Expected results:
When listing subnets, the client should list those matching both the name and tag conditions.

Additional info:
Verified on an OpenStack 16.1.6 environment with Cisco ACI integration. Could not reproduce it on RHOSP 16.1.6 with OVS and without ACI.
Comment 2 Eric Nothen 2021-11-30 10:28:36 UTC 
Received the following information from Cisco:

This is a bug in ACI plugin OSP16 implementation. We created the following patch/workaround to work around a bug in upstream neutron:

https://review.opendev.org/c/x/group-based-policy/+/771464

 
In parallel this patch was submitted https://review.opendev.org/c/openstack/neutron/+/771155 to upstream to fix the original issue.


The 771464 patch introduced the get subnets bug, but the patch was needed until the upstream patches merged (see https://review.opendev.org/q/Ifb9df94128b7069e78e193bc289be17e15968167).

Those merged in January of this year. We believe that OSP16.1.4 is the first release that contained these fixes, and as a result, would therefore be usable if we revert the above patch/workaround in our plugin.
Comment 3 Rodolfo Alonso 2021-12-02 12:35:14 UTC 
Hello Eric:

Neither [1] nor [2] are in 16.1. Those U/S patches were not rebased into 16.1 (they are in 16.2). Thus this cannot be the culprit of this problem. The workaround in GBP is not necessary in this deployment.

Apart from OpFlex, what other plugins/extensions/add-ons have this Cu deployment?

Regards.

[1]https://review.opendev.org/q/Id5d8ac09a38c656619f88a6f87b8f384fe4c55a8
[2]https://review.opendev.org/q/Ifb9df94128b7069e78e193bc289be17e15968167
Comment 4 Eric Nothen 2021-12-03 09:12:31 UTC 
Rodolfo, I followed up with with my customer's Cisco TAM. There's no other plugin on this environment apart from the ACI neutron plugin (OpFlex). They also sent me the following message from development:

~~~
I did check, and saw that these patches aren’t in our 16.1 deployment. Therefore, removing our workaround (which wasn’t needed) still fixes things, and doesn’t break anything (and will work for 16.2 as well).
~~~

The workaround patch that they are talking about is this https://review.opendev.org/c/x/group-based-policy/+/771464


Would it be better if we look at sosreports from some of their controllers, or is there anything I can ask the customer to provide from their environment?
Comment 5 Rodolfo Alonso 2021-12-03 09:26:18 UTC 
Hello Eric:

Is the customer using Group Based Policy? Because the patch you are referring [1] is for this project.

Sosreports could provide some information but I'm not sure about it. The command returns without any error and logs do not provide the code path followed. As commented, there should be something else (plugin, extension) configured. If not, the behaviour described is not possible with Neutron 16.1.6 base code.

Regards.

[1]https://review.opendev.org/c/x/group-based-policy/+/771464
Comment 7 Eric Nothen 2021-12-06 08:19:39 UTC 
(In reply to Rodolfo Alonso from comment #5)
> Hello Eric:
> 
> Is the customer using Group Based Policy? Because the patch you are
> referring [1] is for this project.

My understanding is that they are not, just ML2. I think the change on group-based-policy is introduced by Cisco to workaround the main issue that comes from upstream Neutron. for which they issued a revert. This comes from my exchange with the Cisco TAM. If the commit that originates the issue is not on 16.1, then I don't know what the problem is.

If you want to connect with a developer at Cisco, I can ask the TAM so that you can discuss directly.