As per the move to the conductor, it was also agreed on not leaving the scheduler know the list of instance_uuids
Consequently, the recent Scheduler RPC API version bump (4.0) removed that field from the request_spec which was passed in because it was no longer needed.
If we want to backtrack which instance was failing with the logs, we then only have 2 possibilities :
#1 request_spec still continues to provide a full information of the first instance being requested, including its uuid - so we can show this up but it would only be accurate for the first one
#2 that instance information still includes an EC2-compatible field called reservation_id which is set even for OpenStack API and describe the request by itself. We can show it up too.
As per the move to the conductor, it was also agreed on not leaving the scheduler know the list of instance_uuids
Consequently, the recent Scheduler RPC API version bump (4.0) removed that field from the request_spec which was passed in because it was no longer needed.
If we want to backtrack which instance was failing with the logs, we then only have 2 possibilities :
#1 request_spec still continues to provide a full information of the first instance being requested, including its uuid - so we can show this up but it would only be accurate for the first one
#2 that instance information still includes an EC2-compatible field called reservation_id which is set even for OpenStack API and describe the request by itself. We can show it up too.