User can't know which flavor used for resize by the result of "nova migration-list"

[Charlotte Han]

Description
===========
Users use "nova migration-list | grep resize" to see resize operation records, but they can't know which flavor is used for resize. Because "migrations" table record new flavor information using flavor's id which is consistent with "id" in "flavors" table, but users only can see 'flavorid' by "nova flavor-list".

Steps to reproduce
==================
* I did create two flavor
 nova flavor-create test_01 test_01 128 1 1
 nova flavor-create test_02 test_02 256 2 2

* then I did create an instance
  nova boot --flavor test_01 --image abac216f-db4f-4c69-9d44-18405cf84d8f --nic net-id=ba8d7500-2d2a-425f-83b3-ffa45a5ad28a test_resize

* then I did resize instance from test_01 to test_02
   nova resize e0661223-6ff0-461e-a9e4-f1db9be21787 test_02

* the I did look for resize migration records
   nova migration-list | grep resize
| 204 | computer1 | ctrl3 | computer1 | ctrl3 | 193.168.1.13 | finished | e0661223-6ff0-461e-a9e4-f1db9be21787 | 1 | 2 | 2017-11-26T04:22:57.000000 | 2017-11-26T04:23:09.000000 | resize |

old flavor is 1, new flavor is 2

* I did search all flavors
nova flavor-list
+------------+--------------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+------------+--------------+-----------+------+-----------+------+-------+-------------+-----------
| test_01 | test_01 | 128 | 1 | 0 | | 1 | 1.0 | True |
| test_02 | test_02 | 256 | 2 | 0 | | 2 | 1.0 | True
+------------+--------------+-----------+------+-----------+------+-------+-------------+-----------+

Expected result
===============
As a user, I want to know which flavor is "2"?
for example:
 nova migration-list | grep resize
| 204 | computer1 | ctrl3 | computer1 | ctrl3 | 193.168.1.13 | finished | e0661223-6ff0-461e-a9e4-f1db9be21787 | test_01 | test_02 | 2017-11-26T04:22:57.000000 | 2017-11-26T04:23:09.000000 | resize |

Actual result
=============
User can't know what kind of flavor is "2"?

Environment
===========
1. Exact version of OpenStack you are running. See the following
  list for all releases: http://docs.openstack.org/releases/
   Pike

[Charlotte Han (hanrong)]

nova migration-list return flavorid instead of instance_type_id.
I will upload a patch set to fix it.

[Matt Riedemann (mriedem)]

The problem isn't in novaclient, it's in the server code that creates the migration record. It's recording the old/new instance type ids using the internal primary keys for the flavor, rather than the flavorid which is the user-facing id for a flavor:

https://github.com/openstack/nova/blob/5b5b5c8df316e4c26b853c80ae8f8ea91f9c05c0/nova/conductor/tasks/migrate.py#L180-L181

Changing that is technically an API change, but leaking unusable flavor.id primary keys out of the REST API isn't useful either.

The other problem here is the migration old/new instance type columns are integers, not strings, and flavor.flavorid is a string.

    old_instance_type_id = Column(Integer())
    new_instance_type_id = Column(Integer())

So even if we wanted to store the flavorid string in the migration record, we can't right now because of the column type in the database.

What we could maybe do is change the os-migrations API to lookup the flavor by the id primary key and return the flavorid, however, flavors are now stored in the API database and they are not soft deleted, meaning once a flavor is deleted it's gone, so older migration records might not be able to find the old flavor ids in the API database.

We could potentially pull the old/new instance type off the instance record (which also records that information).

[Matt Riedemann (mriedem)]

From what I can see, nothing else in the code relies on the migration.old/new_instance_type_id fields, only the REST API, so we store the entirely wrong thing and return it out of the REST API.

[Matt Riedemann (mriedem)]

We probably can't get the old/new flavor information off the instance either, because the migration.instance_uuid record points at an instance but the old/new flavor in that instance might no longer match that specific migration record, e.g. if I have resized an instance twice, from flavor A->B and then flavor B->C, there would be 2 migration records pointing at the same instance but the first migration can't get the old/new flavors off the instance because the current old/new flavors on the instance record are B/C, not A/B.

The only way I see that we can really fix this is to change the migrations.old/new_instance_type columns in the database so we can store the flavorid (string) rather than the flavor.id (int).

[Matt Riedemann (mriedem)]

Even if we stored the flavorid in the migrations table and returned that out of the migrations API, the flavorid doesn't tell you much - and the flavor for that flavorid might be deleted for really old migration records. This is why we did microversion 2.47 https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id42 where the full embedded flavor is returned for the GET /servers/detail response, and I'm not advocating that we store the full flavor information in the migrations table.

So the alternative option for the problem migrations API is we could simply microversion out the old/new_instance_type fields from the response since they aren't very useful. I'm not sure how much people need to know which flavors were used in a users resize operation anyway.

[Charlotte Han (hanrong)]

As far as I am concerned, operation and maintenance personnel always use "nova migration-list" to look for information of resize failure.

[Charlotte Han (hanrong)]

If we pull the old/new_instance_type fields out from the response, what channels do users get one old/new flavor inforation for an special resize operation?

[Balazs Gibizer (balazs-gibizer)]

Nova emits instance.resize notifications with full flavor information[1]. So an external system listening to those notifications can create a history of resizes. The instance.resize.start is emitted with the original flavor and the instance.resize_finish.end is emitted with the new flavor information.

[1] https://docs.openstack.org/nova/pike/reference/notifications.html#existing-versioned-notifications

[Charlotte Han (hanrong)]

Yea，I got it. I will advise operation and maintenance personnels to obtain resize flavor by ceilometer.

I agree that microversion remove old/new_instance_type fields from the response of "nova migration-list".

[Charlotte Han (hanrong)]

I would like to fix this question.
Do I need to submit a blueprint first?