[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.
Best,
-jay
More information about the OpenStack-dev
mailing list