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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
