Neutron allows creating tenants having malformed UUID

[Alexander Rubtsov]

--- Steps to reproduce ---
Create a new SG and specify some text instead of correct tenant-id:
(or specify ID which is in correct format, but SG with this ID is not present)
neutron security-group-create --tenant-id my_favorite_tenant e_sg_bad

--- Actual result ---
There are security groups with incorrect ID created:
mysql> SELECT * FROM securitygroups;
+----------------------------------+--------------------------------------+-----------+------------------+
| tenant_id | id | name | standard_attr_id |
+----------------------------------+--------------------------------------+-----------+------------------+
| e6c08a1fc0f74591b88337fcca169a42 | 6010c510-a5d0-4b0f-b51d-17b8ef55d367 | default | 1 |
| my_favorite_tenant | 9278a7ce-8c7c-4fdc-8b7b-4db0afc21924 | e_sg_bad | 27 |
| my_favorite_tenant | af3cedff-9b1b-4a80-838c-f8ce3153804f | default | 22 |
+----------------------------------+--------------------------------------+-----------+------------------+

--- Expected result ---
An error which tells that the specified tenant-id doesn't exist

--- Notes ---
Even simple listing of security groups creates new security groups for the non-existing tenants.
root@node-6:~# neutron security-group-list --tenant-id pls_dont_create_anything_i_just_want_to_see_the_list
+--------------------------------------+---------+----------------------------------------------------------------------+
| id | name | security_group_rules |
+--------------------------------------+---------+----------------------------------------------------------------------+
| df826686-0074-4075-a7d9-4fc1d45627e2 | default | egress, IPv4 |
| | | egress, IPv6 |
| | | ingress, IPv4, remote_group_id: df826686-0074-4075-a7d9-4fc1d45627e2 |
| | | ingress, IPv6, remote_group_id: df826686-0074-4075-a7d9-4fc1d45627e2 |
+--------------------------------------+---------+----------------------------------------------------------------------+

root@node-6:~# mysql -D neutron -e "SELECT * FROM securitygroups;"
+------------------------------------------------------+--------------------------------------+------------+------------------+
| tenant_id | id | name | standard_attr_id |
+------------------------------------------------------+--------------------------------------+------------+------------------+
| e6c08a1fc0f74591b88337fcca169a42 | 6010c510-a5d0-4b0f-b51d-17b8ef55d367 | default | 1 |
| pls_dont_create_anything_i_just_want_to_see_the_list | df826686-0074-4075-a7d9-4fc1d45627e2 | default | 48 |
+------------------------------------------------------+--------------------------------------+------------+------------------+

This behavior is described here:
https://bugs.launchpad.net/neutron/+bug/1653025
https://bugs.launchpad.net/python-openstackclient/+bug/1732716

[Alexander Rubtsov (arubtsov)]

sla1 for 9.0-updates

[Denis Meltsaykin (dmeltsaykin)]

Alexander, please clarify the impact. Are workloads affected by the issue?

[Alexander Rubtsov (arubtsov)]

The impact reported by a customer who has hit the issue:

All the Services implemented in Openstack and the OpenDaylight SDN controller enforce tenant isolation in the dataplane for all the tenants. However, in the control plane common models/tables are used which hold all the different tenant information together. Now that said, in SDN-based deployments that run Openstack Mitaka, even if single row in Neutron DB is corrupted, it has the potential to
affect all the future orchestrations not just for that tenant, but for all the existing / new tenants. This is a limitation with the Mitaka version of the Openstack OpenDaylight V1 Driver of Neutron community.

Due to the corrupted rows in the table causing ODL Neutron V1 Driver to continuously thrash the system thereby making it consume more memory as well as taking away lot of CPU cycles .

[Denis Meltsaykin (dmeltsaykin)]

Moving to 9.2-mu-8 since there are no fix yet alongside with the absent agreement that it's even a bug.

[Oleg Bondarev (obondarev)]

Quoting Graham Hayes (grahamhayes): "Not all project IDs are UUIDs unfortunately - in the past I have worked on clouds were they were ints, The keystone validator is very loose [1]
...
1 - https://github.com/openstack/keystone/blob/b9dee7332374d9a382c8403d646909e0c70a90ac/keystone/common/validation/parameter_types.py#L38-L45
"[2]
So we can't just add validation into Neutron for tenant_id to be UUID - this is incorrect, won't be accepted by upstream and more importantly may break existing customers deployments.

The proper way would be to validate all tenant IDs with keystone like was done in nova [3] and currently is being replicated in designate [4].

If we are to replicate this in Neutron then the validation code should be refactored to a common library (oslo) and be used from all projects where needed. This is an upstream master feature which will take significant time to land.
Even if implemented, these patches will be hardly backportable to Mitaka (which is 5-6 releases back).
Given above - closing as won't fix.

A recommendation would be to maybe fix this in ODL V1 driver by handling/skipping a non-UUID exception which should be fairly simple and backportable unless I'm too naive.

[2] https://bugs.launchpad.net/designate/+bug/1760822/comments/6
[3] https://review.openstack.org/#/c/435010/
[4] https://review.openstack.org/#/c/576219/