On 5/30/2018 5:21 AM, Massimo Sgaravatto wrote:
The problem is indeed with the tenant_id
When I create a VM, tenant_id is ee1865a76440481cbcff08544c7d580a
(SgaraPrj1), as expected
But when, as admin, I run the "nova migrate" command to migrate the very
same instance, the tenant_id is 56c3f5c047e74a78a71438c4412e6e13 (admin) !
OK that's good information.
Tracing the code for cold migrate in ocata, we get the request spec that
was created when the instance was created here:
https://github.com/openstack/nova/blob/stable/ocata/nova/compute/api.py#L3339
As I mentioned earlier, if it was cold migrating an instance created
before Newton and the online data migration wasn't run on it, we'd
create a temporary request spec here:
https://github.com/openstack/nova/blob/stable/ocata/nova/conductor/manager.py#L263
But that shouldn't be the case in your scenario.
Right before we call the scheduler, for some reason, we completely
ignore the request spec retrieved in the API, and re-create it from
local scope variables in conductor:
https://github.com/openstack/nova/blob/stable/ocata/nova/conductor/tasks/migrate.py#L50
And *that* is precisely where this breaks down and takes the project_id
from the current context (admin) rather than the instance:
https://github.com/openstack/nova/blob/stable/ocata/nova/objects/request_spec.py#L407
Thanks for your patience in debugging this Massimo! I'll get a bug
reported and patch posted to fix it.
--
Thanks,
Matt
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
