[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