Open Stack

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