Florian-

You can definitely delete a flavor [1].

Don't worry about it affecting existing instances that were created with that flavor: nova stores a copy of the flavor with the instance itself so the information is preserved.

Thanks for the question!

On Fri, 2019-03-29 at 11:25 -0500, Eric Fried wrote: the other option if you want to keep the flavor but not make it usable by new instances in general is to use the os-flavor-access api. https://developer.openstack.org/api-ref/compute/?expanded=#flavors-access-fl... This allows you to make a flavor private and control what project can use it. unfortunetly we seam to have almost no documentation for this however that is what the --project argument to openstack flavor set is used to contol. https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/f... e.g. openstack flavor set --project <my admin/hidden project> <flavor i want to retire> this will allow you to retire the flavor more selectively. so if you have a important customer that needs a little more time to move to your new flavor offerings you can similarly add them to the now private flavor to aide there transition before you actually delete it. as efried said you can delete the flavor without issue so if you are not worred about it breaking ci or other automation and can simply remove the flavor that hsould be safe to do so.

-efried

[1] https://docs.openstack.org/nova/latest/admin/flavors.html#delete-a-flavor

On 3/29/19 10:43 AM, Florian Engelmann wrote:

...

Hi,

I would like to retire old flavors we don't want to be use any more. I guess deleting is the wrong way to retire flavors? I was not able to find any documentation about how the life-cycle of a flavor works.

Any help is very welcome.

All the best, Florian

On Mon, 2019-04-01 at 17:40 +0200, Florian Engelmann wrote:

Hi,

as far as I tested it is not possible to change a flavor from public to private. Managing access to flavors on a project basis might be an option for a private cloud but not for a public one. if you cannot retrict a flavor to a singel porject in a public cloud you also can never delete a flavor in a public cloud.

from an api perspective it will have the same effect.

There are a lot of unit tests about:

"alias": "OS-FLV-DISABLED", "description": "Support to show the disabled status of a flavor.",

What's that feature for? How does it work? Is this ongoing?

I think we need some method to retire images and flavors.

well it depend on what you mean by retire. my definition of retire means it still exist but is no longer requestable for new instances. idealy if you retire something from service it should be possible to reinstate it again even if that is unlikely. if your definitoin of retire delete it then you can certenly do that. restoring a delete flavor is technicaly possible as you cna just recreated it but its harder to do that then unrestrict the acess to the flavor. but yes we shoudl have a documented procedure to "retire" a flavor or image in the admin guide somewhere but we also need to define what that means first and that might change form deployment to deployment at least in some cases.

All the best, Florian

Am 3/31/19 um 11:57 AM schrieb Sean Mooney:

...

On Fri, 2019-03-29 at 11:25 -0500, Eric Fried wrote:

...

Florian-

You can definitely delete a flavor [1].

Don't worry about it affecting existing instances that were created with that flavor: nova stores a copy of the flavor with the instance itself so the information is preserved.

Thanks for the question!

the other option if you want to keep the flavor but not make it usable by new instances in general is to use the os-flavor-access api. https://developer.openstack.org/api-ref/compute/?expanded=#flavors-access-fl... This allows you to make a flavor private and control what project can use it.

unfortunetly we seam to have almost no documentation for this however that is what the --project argument to openstack flavor set is used to contol. https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/f... e.g. openstack flavor set --project <my admin/hidden project> <flavor i want to retire>

this will allow you to retire the flavor more selectively. so if you have a important customer that needs a little more time to move to your new flavor offerings you can similarly add them to the now private flavor to aide there transition before you actually delete it.

as efried said you can delete the flavor without issue so if you are not worred about it breaking ci or other automation and can simply remove the flavor that hsould be safe to do so.

...

-efried

[1] https://docs.openstack.org/nova/latest/admin/flavors.html#delete-a-flavor

On 3/29/19 10:43 AM, Florian Engelmann wrote:

...

Hi,

I would like to retire old flavors we don't want to be use any more. I guess deleting is the wrong way to retire flavors? I was not able to find any documentation about how the life-cycle of a flavor works.

Any help is very welcome.

All the best, Florian

On 4/1/2019 8:40 AM, Florian Engelmann wrote:

There are a lot of unit tests about:

            "alias": "OS-FLV-DISABLED",             "description": "Support to show the disabled status of a flavor.",

What's that feature for? How does it work? Is this ongoing?

The flavor.disabled attribute was added a long long time ago and has no external API hook or even nova-manage CLI to change the value of that attribute, so if you want to set it you have to do it in the database manually (yes, it sucks, it's half-baked, and I don't know if we should just remove it or officially support it in the API).

I think we need some method to retire images and flavors.

Agreed, please report a nova bug for retiring a flavor. As for retiring an image, I already pointed out there is a story for that: https://storyboard.openstack.org/#!/story/2004892 But that's not really a nova bug. -- Thanks, Matt

On Fri, 2019-04-05 at 14:30 +0200, Florian Engelmann wrote:

...

...

I think we need some method to retire images and flavors.

Agreed, please report a nova bug for retiring a flavor.

As for retiring an image, I already pointed out there is a story for that:

https://storyboard.openstack.org/#!/story/2004892

But that's not really a nova bug.

I will create a bug report. I think it is a important feature. its an api change so it will reuquire a nova spec. can you file a blueprint instead and then we can write up a small spec for this later.

On Fri, 2019-04-05 at 13:01 -0500, Matt Riedemann wrote:

On 4/5/2019 7:45 AM, Sean Mooney wrote:

...

its an api change so it will reuquire a nova spec. can you file a blueprint instead and then we can write up a small spec for this later.

What are we talking about specifically? We have a method for retiring flavors, you can make them private or delete them. I wasn't suggesting we should add the ability to change the flavor.disabled value in the API which would require a spec. I was asking Florian to report a nova bug about the lack of documentation for how to retire a flavor, that's all. ya i think that makes sense. we shoudl have a bug for the documention gap.

the blueprint reply was to http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004624.htm... my assertion that there should be a blueprint and not a bug was because that would be an api change. although i might have replied to the wrong email. florain sent 2 emails back to back i think the existing mechanism we have are likely sufficient provided we document how to use them so a bug as you suggested will be enough.

On 4/1/2019 9:39 AM, Massimo Sgaravatto wrote:

Is this the case also if the extra_specs field attribute was set for the flavor and the AggregateInstanceExtraSpecsFilter filter is used ? Aren't there problems rescheduling an instance created with that flavor ?

Rescheduling uses the RequestSpec, which contains a copy of the Flavor from the last resize or when the server was initially created. The RequestSpec is around for the lifetime of the instance, so you can delete the original flavor and still reschedule. 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. -- Thanks, Matt

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.