To summarize some of the conversation related to the planned fix for stein, where something like `uuid=in:{uuid},{uuid}` would be added:
The challenge with this is determining which resource providers those uuids would match. In a nested or sharing scenario, we presumably don't want to require (since we may not even know them) that all the resource provider uuids in the collection of allocations for this one vm be represented in the in `uuid` parameter.
We could make it so that the uuids are only "anchor" providers, which means in the "force_hosts" case the uuids of the resource providers representing the hosts being targeted would be listed in the parameter.
This makes some logical sense, but may be a nova-ism.
It's also not clear if the idea of an "anchor" or "target" is sufficiently clear in the database query code to be able to do the equivalent of "where anchor.uuid in(uuids_from_param)".
To summarize some of the conversation related to the planned fix for stein, where something like `uuid=in: {uuid}, {uuid}` would be added:
The challenge with this is determining which resource providers those uuids would match. In a nested or sharing scenario, we presumably don't want to require (since we may not even know them) that all the resource provider uuids in the collection of allocations for this one vm be represented in the in `uuid` parameter.
We could make it so that the uuids are only "anchor" providers, which means in the "force_hosts" case the uuids of the resource providers representing the hosts being targeted would be listed in the parameter.
This makes some logical sense, but may be a nova-ism.
It's also not clear if the idea of an "anchor" or "target" is sufficiently clear in the database query code to be able to do the equivalent of "where anchor.uuid in(uuids_ from_param) ".