Open Stack

On Fri, 2019-04-05 at 14:33 +0100, Graham Hayes wrote:
> On 01/04/2019 17:48, Matt Riedemann wrote:
> 
> > Now if you created a server or resized a server with a given flavor, and
> > then modified that flavors extra_specs, that won't be reflected back in
> > the persisted RequestSpec, but it's probably not a great idea in general
> > to modify extra_specs on public flavors which are already being used.
> > 
> 
> There is a use case for this - if you have heterogeneous compute
> environment (e.g. some nodes are set up for pinning, some for standard
> overcommit, some for one to one (no over commit, but not pinned)), and
> you make a mistake - being able to change the flavor makes fixing the
> resultant mess a lot easier - especially if you can update the
> RequestSpec to match the new flavor.
there is a problem statemnt certenly
whether that problemstatyme is a valid usecase we shoudl supprot is another matter.

one way to adders this use casue is via flavor validation to prevent you
creating an invalid flavor in the first place.

it is generally not safe to update a flavor on a runnign instance as
that update may invalidate the current placment of the vm or change the comptue context
that is created by change resource usage or even hypervior type depending on the way the
flavor was updated.

i think this problem statement is valid but i dont think its the same as i have a falvor
and i want to retrie it form use.
> 
> Without this (or doing DB surgery), the end result is potentially
> resizing all the VMs in a region, which is not always possible (SR-IOV
> or really large VMs that can't really be shutdown).
> 
> This is generally for provisioning suites that hardcode flavor IDs and
> names into deployment templates, but unfortunately there quite a few of
> them that still do this, even in newer versions.

yes but in the case of a typo or mistake like this the only option that is vaild for existing
is a resize. if the typo was in the extraspecs you can updated them currently however
if i could change that without breaking the world i would much prefer if extra_specs were
imutable as the other flavor atribute are. that will never happen so ill move on but
to update the embded flavor whenever we update the flavor in the api db would effectvly
require us to live with instance that are invalidly placed (you added a constraitn that forced
would have force the sellection of a differnet host aggraget) , have invalide state 
( e.g. you added a numa topology to the flavor or pinning) or would require use to live or cold
migrate the instace to make them comply with the new flavor.

i think that would make thing worse then our currnet state.
we allow operator to change extra_specs because it does make correcting mistakes simpler
but we advise againt it in general as there are sharp edges and there is not simple way
mitigate that.