[nova] Proper way to regenerate request_specs of existing instances?

Sean Mooney smooney at redhat.com
Tue Jun 1 21:14:45 UTC 2021


On Tue, 2021-06-01 at 18:06 +0200, Patryk Jakuszew wrote:
> On Tue, 1 Jun 2021 at 14:35, Sylvain Bauza <sbauza at redhat.com> wrote:
> > In general, this question is about AZs : as in general some operators want to modify the AZ value of a specific RequestSpec, this would also mean that the users using the related instance would not understand why now this instance would be on another AZ if the host is within another one.
> 
> To be more specific: we do have AZs already, but we also want to add
> AggregateInstanceExtraSpecsFilter in order to prepare for a scenario
> with having multiple CPU generations in each AZ.

the supported way to do that woudl be to resize the instance.
nova currently does not suppout updating the embedded flavor any other way.
that said this is yet another usecase for a recreate api that would allow updating the embedded flavor and image metadta.

nova expect flavours to be effectively immutable once an instace start to use them.
the same is true of image properties so partly be design this has not been easy to support in nova because
it was a usgage model we have declard out of scope.

the solution that is vaiable today is rebuidl ro resize but

a recreate api is really want you need.
> 
> > As you said, if you really want to modify the RequestSpec object, please then write a Python script that would use the objects class by getting the RequestSpec object directly and then persisting it again.
> 
> Alright, I will try that again, but using the Nova objects class as you suggest.

this has come up often enough that we __might__ (im stressing might since im not sure we really want to do this)
consider adding a nova manage command to do this.

e.g. nova-mange instance flavor-regenerate <instance uuid> and nova-mange instance image-regenerate <instance uuid>

those command woudl just recrate the embeded flavor and image metadta without moving the vm or otherwise restarting it.
you would then have to hard reboot it or migrate it sepereatlly.

im not convicned this is a capablity we should provide to operators in tree however via nova-manage.

with my downstream hat on im not sure how supportable it woudl for example since like nova reset-state it woudl be
very easy to render vms unbootable in there current localthouh if a tenatn did a hard reboot and cause all kinds of stange issues
that are hard to debug an fix.




> 
> Thanks for the answer!
> 
> --
> Regards,
> Patryk
> 





More information about the openstack-discuss mailing list