On 07/06/2018 10:09 AM, Chris Dent wrote:
* 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:
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 .
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.
 For those curious, nova-scheduler calls
which itself calls reportclient.claim_resources(...) with the
instance.user_id and instance.project_id values:
The instance.project_id and instance.user_id values are populated from
the WSGI environ here:
OpenStack Development Mailing List (not for usage questions)