Comment 2 for bug 1734504

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