[RFE] project ID is not verified when creating neutron resources

[Crazik]

Environment: Ocata

According to current docs, in order to create auto-allocated network in tenant, following command should be invoked:

`neutron auto-allocated-topology-show [project_id]`

Unfortunatelly, this command does not verify if given project exists, so it's easy to create completely unusefull network components, even breaking naming convention for project_id field in database tables.

Example:

» neutron auto-allocated-topology-show 37-e088febf-64bd-4b5e-b4dd-1f5a80e
+------------+--------------------------------------+
| Field | Value |
+------------+--------------------------------------+
| id | 63f5f696-8a64-4bbb-af1e-b55a26f78f38 |
| project_id | 37-e088febf-64bd-4b5e-b4dd-1f5a80e |
| tenant_id | 37-e088febf-64bd-4b5e-b4dd-1f5a80e |
+------------+--------------------------------------+

»

[Armando Migliaccio (armando-migliaccio)]

None of the neutron commands do.

[Armando Migliaccio (armando-migliaccio)]

As admin, you could create a network for a tenant that does not exist. This is a 'well-known gotcha'. To address this we'd have to have neutron talk to Keystone to validate that the UUID is a valid one. Doable, but we never go around to do it for a variety of reasons (performance being one of them).

[Armando Migliaccio (armando-migliaccio)]

Let's gather feedback at the drivers meeting.

[YAMAMOTO Takashi (yamamoto)]

something similar in nova: https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/validate-project-with-keystone.html

[Miguel Lavalle (minsel)]

This was discussed during the latest drivers meeting: http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-10-27-14.00.log.html#l-110. If the problem is exclusively typos when using the CLI, we could handle this in the client. Is this something that would work in your scenario / use case?

[Crazik (crazik)]

How do you want to check typo? Match given project-id to user's project-id?
I expected some checks like 'match if project exists with given project-id', then yes, my use case is safe then.

[Armando Migliaccio (armando-migliaccio)]

We could check that the project ID is an actual UUID. The most natural source of errors when specifying project IDs is unrecognized copy and paste errors.

[Miguel Lavalle (minsel)]

@Crazik

We discussed today this RFE again during the Drivers meeting. The OpenStack client (OSC) verifies the project id with Keystone for most commands. Auto allocated topology is an exception. We think that should be considered as a bug in OSC. If this were fixed in OSC, the use case you describe here would be supported. Have you considered filing a bug with OSC?

[Miguel Lavalle (minsel)]

We revisited this RFE on December 22nd meeting. If by next meeting, January 5th, we don't hear back from submitter, we will assume this can be solved by OSC and classify it as an OSC bug