[openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

Jay Pipes jaypipes at gmail.com
Wed May 2 22:39:54 UTC 2018

On 05/02/2018 10:07 AM, Matt Riedemann wrote:
> On 5/1/2018 5:26 PM, Arvind N wrote:
>> In cases of rebuilding of an instance using a different image where 
>> the image traits have changed between the original launch and the 
>> rebuild, is it reasonable to ask to just re-launch a new instance with 
>> the new image?
>> The argument for this approach is that given that the requirements 
>> have changed, we want the scheduler to pick and allocate the 
>> appropriate host for the instance.
> We don't know if the requirements have changed with the new image until 
> we check them.
> Here is another option:
> What if the API compares the original image required traits against the 
> new image required traits, and if the new image has required traits 
> which weren't in the original image, then (punt) fail in the API? Then 
> you would at least have a chance to rebuild with a new image that has 
> required traits as long as those required traits are less than or equal 
> to the originally validated traits for the host on which the instance is 
> currently running.

That's pretty much what I had suggested earlier, yeah.

> Option 10: Don't support image-defined traits at all. I know that won't 
> happen though.
> At this point I'm exhausted with this entire issue and conversation and 
> will probably bow out and need someone else to step in with different 
> perspective, like melwitt or dansmith.
> All of the solutions are bad in their own way, either because they add 
> technical debt and poor user experience, or because they make rebuild 
> more complicated and harder to maintain for the developers.

I hear your frustration. And I agree all of the solutions are bad in 
their own way.

My personal preference is to add less technical debt and go with a 
solution that checks if image traits have changed in nova-api and if so, 
simply refuse to perform a rebuild.


More information about the OpenStack-dev mailing list