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.
On Fri, 2019-04-05 at 14:33 +0100, Graham Hayes wrote: 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.