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