Open Stack

On 07/06/2018 10:09 AM, Chris Dent wrote:
> # Questions
> 
> * Will consumer id, project and user id always be a UUID? We've
>    established for certain that user id will not, but things are
>    less clear for the other two. This issue is compounded by the
>    fact that these two strings are different but the same UUID:
>    5eb033fd-c550-420e-a31c-3ec2703a403c,
>    5eb033fdc550420ea31c3ec2703a403c (bug 1758057 mentioned above) but
>    we treat them differently in our code.

As mentioned by a couple people on IRC, a consumer's external project 
identifier and external user identifier come directly from Keystone. 
Since Keystone has no rule about these values being UUIDs or even 
UUID-like, we clearly cannot treat them as UUIDs in the placement service.

Our backend data storage for these attributes is suitably a String(255) 
column and there is no validation done on these values. In fact, the 
project and user external identifiers are taken directly from the 
nova.context WSGI environ when sending from the placement client [1].

So, really, the only thing we're discussing is whether consumer_id is 
always a UUID.

I believe it should be, and the fact that it's referred to as 
consumer_uuid in so many places should be indicative of its purpose. I 
know originally the field in the DB was a String(64), but it's since 
been changed to String(36), further evidence that consumer_id was 
intended to be a UUID.

I believe we should validate it as such at the placement API layer. The 
only current consumers in the placement service are instances and 
migrations, both of which use a UUID identifier. I don't think it's too 
onerous to require future consumers to be identified with a UUID, and it 
would be nice to be able to rely on a structured, agreed format for 
unique identification of consumers across services.

As noted the project_id and user_id are not required to be UUIDs and I 
don't believe we should add any validation for those fields.

Best,
-jay

[1] For those curious, nova-scheduler calls 
scheduler.utils.claim_resources(...):

https://github.com/openstack/nova/blob/8469fa70dafa83cb068538679100bede7679edc3/nova/scheduler/filter_scheduler.py#L219

which itself calls reportclient.claim_resources(...) with the 
instance.user_id and instance.project_id values:

https://github.com/openstack/nova/blob/8469fa70dafa83cb068538679100bede7679edc3/nova/scheduler/utils.py#L500

The instance.project_id and instance.user_id values are populated from 
the WSGI environ here:

https://github.com/openstack/nova/blob/8469fa70dafa83cb068538679100bede7679edc3/nova/compute/api.py#L831-L832