[nova][ops] Migrating instances with old extra specs info.

Roman Dobosz gryf73 at gmail.com
Mon Dec 3 20:58:23 UTC 2018


On Mon, 3 Dec 2018 11:56:17 -0500
Jay Pipes <jaypipes at gmail.com> wrote:

> >>> Is it a bug? Or maybe it is possible to change the instance flavor
> >>> extra spec?
> >> Not sure it's a bug, per-se... might just be something you need to
> > At least unexpected behavior :)
> It's not unexpected behaviour at all. The behaviour of Nova when 
> changing a flavor's details has been (for many releases) that the 
> flavor's details are changed but flavor data for already-launched 
> instances does not change. Just like you can delete a flavor but it 
> doesn't affect already-launched instances because we store the details 
> of the original instance.

For resource related things - sure. As for more ephemeral things 
like metadata - its arguable. Although, I tend to agree, that 
sometimes metadata could potentially hold sensitive information, 
which shouldn't be changed in that case.

> The root of the problem you are experiencing is that flavor extra-specs 
> is a pile of half-standardized random key-value information instead of 
> structured, standardized quantitative and qualitative information 
> (*gasp* that's what resource classes and traits are in placement...)

Yeah, I know. But we have that issue in Newton, where traits are 
nonexistent yet :)

> Which is why I say this isn't actually unexpected behaviour or really a bug.
> 
> >> manually change database records for, though. Sucks, since it's hacky,
> >> but not sure if it's something we should change in the API contract.
> > I'd be happy with nova-manage command for update extra specs in
> > instance info, it doesn't need to be an API change :)
> mysql -u$USER -p$PASSWORD -Dnova -e"UPDATE instance_extra SET flavor = 
> REPLACE(flavor, 'old string', 'new string')"
> 
> There, no need for a nova-manage command.

Well, thank you, kind sir!

> p.s. test the above on a copy of your production DB before you trust 
> it... :)

You bet :)

-- 
Cheers,
Roman Dobosz



More information about the openstack-discuss mailing list