Nova API should present deleted flavors (instance_types) in some cases

Thanks for the patch! It needs to be submitted through gerrit, though.

http://wiki.openstack.org/HowToContribute

See "If you're a developer, start here:"

Thanks for the info! I have found that there are some other issues I
am trying to solve before submitting to gerrit. I did sign the CLA so
that I can contribute it. Hopefully this week will make sense to
submit it.

Actually, perhaps you have a bit of advice on this. The fix in that
patch makes it so that horizon cannot create new flavors (because of
the way it detects the "highest" number flavorId); when dealing with
problems like this that span projects with strange side effects, does
it make sense to make the bug "affect" the other project and try and
submit a patch for both (via gerrit) on the same bug? I am trying to
wade through the best practices of OpenStack for this type of stuff
and any advice would be welcome!

Thanks!
Morgan Fainberg

Sent from my iPad (please excuse any inane typos any autocorrect lameness)

On Apr 21, 2012, at 5:35, Russell Bryant <email address hidden> wrote:

> Thanks for the patch! It needs to be submitted through gerrit, though.
>
> http://wiki.openstack.org/HowToContribute
>
> See "If you're a developer, start here:"
>
> ** Changed in: nova
> Status: New => Triaged
>
> ** Changed in: nova
> Importance: Undecided => Medium
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/981263
>
> Title:
> Nova API should present deleted flavors (instance_types) in some cases
>
> Status in OpenStack Compute (Nova):
> Triaged
>
> Bug description:
> In certain cases Nova API should return instance flavors
> (instance_types) that are deleted. Notably if there is an instance
> that is "active" and the flavor has been deleted, we need to pull the
> instance_type data down to ensure that we can apply network specifics
> attached to that instance_type on startup of nova-compute.
>
> The second case that a deleted flavor should be returned is if the
> instance_type is being requested by ID, as IDs should not be reused.
> This is important for Horizon to be able to properly retrieve
> "instances" for a given project (in Nova Dashboard and Syspanel
> Dashboard).
>
> Example traceback you can see if you delete a flavor and restart nova
> compute:
>
> resource: 'NoneType' object is not subscriptable
> 2012-04-13 19:31:18 TRACE nova.api.openstack.wsgi Traceback (most recent call last):
> 2012-04-13 19:31:18 TRACE nova.api.openstack.wsgi File "/opt/stack/nova/nova/api/openstack/wsgi.py", line 851, in _process_stack
> 2012-04-13 19:31:18 TRACE nova.api.openstack.wsgi action_result = self.dispatch(meth, request, action_args)
> 2012-04-13 19:31:18 TRACE nova.api.openstack.wsgi File "/opt/stack/nova/nova/api/openstack/wsgi.py", line 926, in dispatch
> 2012-04-13 19:31:18 TRACE nova.api.openstack.wsgi return method(req=request, **action_args)
> 2012-04-13 19:31:18 TRACE nova.api.openstack.wsgi File "/opt/stack/nova/nova/api/openstack/compute/servers.py", line 382, in detail
> 2012-04-13 19:31:18 TRACE nova.api.openstack.wsgi servers = self._get_servers(req, is_detail=True)
> 2012-04-13 19:31:18 TRACE nova.api.openstack.wsgi File "/opt/stack/nova/nova/api/openstack/compute/servers.py", line 465, in _get_serv...

I agree that we need access to deleted instance types internally (within Nova), but I don't want to expose them through the public API. flavor_id is designed to be reused, while instance_type_id is the autoincrement unique id used internally. We do have a uniqueness requirement on flavor_id when deleted=0, but other than that it shouldnt matter.

Ideally we would treat flavors totally differently and simply apply the resources to an instance at boot, rather than preserving the tie to a separate table. Our current approach is very fragile and cumbersome.

I would like to know what is the resolution of this bug. We are seeing an issue when horizon issues a flavor get() method, it returns the deleted instance of the flavor. Is that the intended behavior?

On the horizon side of things, when editing a flavor, it does the following:
- Get the flavor data by using get() method for the flavor_id and populates the edit form (the flavor data may be stale)
- On submit, it deletes the flavor_id and recreates a new flavor_id (max (flavor_ids) + 1) with the updates params

The problem is that if you have happen to edit the largest flavor id on horizon, you get the initial _data in the form filled with the details of the deleted flavor_id

Vinay

Following is the observation currently after I setup devstack:

rajalakshmi_ganesan@hsd000176:~$ nova flavor-create test-1 1234 512 1 1
+------+--------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | extra_specs |
+------+--------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| 1234 | test-1 | 512 | 1 | 0 | | 1 | 1.0 | True | {} |
+------+--------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
rajalakshmi_ganesan@hsd000176:~$ nova flavor-list
+------+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | extra_specs |
+------+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| 1 | m1.tiny | 512 | 0 | 0 | | 1 | 1.0 | True | {} |
| 1234 | test-1 | 512 | 1 | 0 | | 1 | 1.0 | True | {} |
| 2 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True | {} |
| 3 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True | {} |
| 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True | {} |
| 5 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True | {} |
+------+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
rajalakshmi_ganesan@hsd000176:~$ nova flavor-delete 1234
rajalakshmi_ganesan@hsd000176:~$ nova flavor-list
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | extra_specs |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
| 1 | m1.tiny | 512 | 0 | 0 | | 1 | 1.0 | True | {} |
| 2 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True | {} |
| 3 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True | {} |
| 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True | {} |
| 5 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True | {} |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+
rajalakshmi_ganesan@hsd000176:~$nova flavor-show 1234
+----------------------------+--------+
| Property | Value |
+----------------------------+--------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 1 |
| extra_specs | {} |
| id | 1234 ...

This was fixed at some point, probably after several recent changes, and is no longer an issue according to the reporter.