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. 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.