Open Stack

On 04/23/2018 03:48 PM, Matt Riedemann wrote:
> We seem to be at a bit of an impasse in this spec amendment [1] so I 
> want to try and summarize the alternative solutions as I see them.
> 
> The overall goal of the blueprint is to allow defining traits via image 
> properties, like flavor extra specs. Those image-defined traits are used 
> to filter hosts during scheduling of the instance. During server create, 
> that filtering happens during the normal "GET /allocation_candidates" 
> call to placement.
> 
> The problem is during rebuild with a new image that specifies new 
> required traits. A rebuild is not a move operation, but we run through 
> the scheduler filters to make sure the new image (if one is specified), 
> is valid for the host on which the instance is currently running.

What you are discussing above is simple a validation that the compute 
node performing the rebuild for an instance supports the capabilities 
that were required by the original image.

How about just having the conductor call GET 
/resource_providers?in_tree=<CN_UUID>&required=<IMAGE_TRAITS>, see if 
there is a result, and if not, don't even call the scheduler at all 
(because conductor would already know there would be a NoValidHost 
returned)?

If there's no image traits,  or if there is a result from GET 
/resource_providers, continue to do the existing call-the-scheduler 
behaviour in order to fulfill the ComputeCapabilitiesFilter and 
ImageMetadataFilter requirements that exist today.

So, in short, just do a quick pre-flight check from the conductor if 
image traits are found before ever calling the scheduler. Otherwise, 
proceed as normal.

Best,
-jay