Bug 1326625

*** Bug 1314866 has been marked as a duplicate of this bug. ***

There was a fix in novaclient merged upstream that prevents failure when showing instances with unavailable flavors: https://review.openstack.org/#/c/170839/

That is, instead of failing, the CLI will say, "Flavor not found" in the situation. This doesn't affect Horizon. Horizon shows it as "Not available" today already.

For the nova patch upstream, it's in -2 state, so I don't think it's a good idea to backport. While the deleted private flavor makes some sense to show on the instance, I don't think the modified flavor makes sense to show. If it's been modified, then it's not accurately describing the attributes of the instance. For example, if the flavor at boot time had 1 VCPU and the flavor is later changed to 2 VCPU, we don't want the display of the instance to say 2 VCPU because it has only 1 VCPU.

So, I think we could backport the novaclient CLI patch if it would be helpful, and we could revisit the nova patch upstream to see if it could be reconsidered in the deleted flavor case as the modified flavor case doesn't make sense, IMHO. Note there is other work in progress to make flavors hard-delete only, so showing a deleted flavor will be impossible in the future.

(In reply to melanie witt from comment #2)
> There was a fix in novaclient merged upstream that prevents failure when
> showing instances with unavailable flavors:
> https://review.openstack.org/#/c/170839/
> 
> That is, instead of failing, the CLI will say, "Flavor not found" in the
> situation. This doesn't affect Horizon. Horizon shows it as "Not available"
> today already.
> 
> For the nova patch upstream, it's in -2 state, so I don't think it's a good
> idea to backport. While the deleted private flavor makes some sense to show
> on the instance, I don't think the modified flavor makes sense to show. If
> it's been modified, then it's not accurately describing the attributes of
> the instance. For example, if the flavor at boot time had 1 VCPU and the
> flavor is later changed to 2 VCPU, we don't want the display of the instance
> to say 2 VCPU because it has only 1 VCPU.
> 
> So, I think we could backport the novaclient CLI patch if it would be
> helpful, and we could revisit the nova patch upstream to see if it could be
> reconsidered in the deleted flavor case as the modified flavor case doesn't
> make sense, IMHO. Note there is other work in progress to make flavors
> hard-delete only, so showing a deleted flavor will be impossible in the
> future.

Correction: Nova API has only flavor create and delete. Horizon presents a "Edit Flavor" button, which does a delete of the old flavor and a create of a new one with the edits. So the upstream nova patch would indeed work in both cases because both cases are about the original flavor at boot time is in deleted state. It's a matter of whether or not we want to backport something which has not merged upstream, combined with the fact that in the future showing of deleted flavors won't be possible as they will be hard-deleted.

I found the novaclient patch that prevents failing when displaying deleted flavors [1] is already part of novaclient rhos-8.0-rhel-7 (upstream novaclient 3.1.0). So it appears there is nothing to do here. Please let me know if that's not the case.

[1] https://review.openstack.org/#/c/170839/

Upstream, the work [1] that moved flavors to the API database was completed and soft-delete capability was removed. So, it's not possible to show deleted flavors today.

However, a copy of flavor attributes for an instance is stored alongside the instance, but is not yet accessible via any API. There is a spec [2] that proposes to add an API for querying flavor information from an instance. If this work is done, it will enable the flavor of an instance to be shown throughout the life of the instance.


[1] https://blueprints.launchpad.net/nova/+spec/flavor-cell-api
[2] https://review.openstack.org/#/c/265282/