Comment 7 for bug 1775934

Revision history for this message
melanie witt (melwitt) wrote :

I'm going to rewrite my comment because I think the last paragraph I wrote is wrong.

I just did a bit of testing with functional tests and found that normally, we can lazy-load a flavor based on a build request just fine (assuming the context is targeted to the correct cell where the instance_extra for the instance record is). But, in Ocata, we aren't targeted to a cell for the instance.get_flavor() call in the nova/api/openstack/compute/views/servers.py code, so we will fail the lazy-load of the flavor.

The key part of this bug is that the build request is being listed in the server list, and a build request will always require a lazy-load of the flavor because the table join on the flavor column will only apply to instance records that are part of the server list.

There are two issues I see:

1. Under normal conditions, a build request will not co-exist with an instance record, and if we need to lazy-load a flavor in the REST API, that will fail because build requests don't have flavors. (Though maybe we could add that?)

2. We aren't handling the possibility of a _set_vm_state_and_notify failure that prevents update of the instance mapping and deletion of the build request.