Open Stack

Continuing the discussion from the nova meeting today [1], I'm trying to 
figure out what the risk / benefit / contingency is if we don't get the 
reshaper stuff done in Rocky.

In a nutshell, we need reshaper to migrate VGPU inventory for the 
libvirt and xenapi drivers from the root compute node resource provider 
to child providers in the compute node provider tree, because then we 
can support multiple VGPU type inventory on the same compute host. [2]

Looking at the status of the vgpu-rocky blueprint [3], the libvirt 
changes are in merge conflict but the xenapi changes are ready to go.

What I'm wondering is if we don't get reshaper done in Rocky, what does 
that prevent us from doing in Stein? For example, does it mean we can't 
support modeling NUMA in placement until the T release? Or does it just 
mean that we lose the upgrade window from Rocky to Stein such that we 
expect people to run the reshaper migration so that Stein code can 
assume the migration has been done and model nested resource providers?

If the former (no NUMA modeling until T), that's a big deal. If the 
latter, it makes the Stein code more complicated but it doesn't sound 
impossible, right? Wouldn't the Stein code just need to add some 
checking to see if the migration has been done before it can support 
some new features?

Obviously if we don't have reshaper done in Rocky then the xenapi driver 
can't support multiple VGPU types on the same compute host in Rocky - 
but isn't that kind of the exact same situation if we don't get reshaper 
done until Stein?

[1] 
http://eavesdrop.openstack.org/meetings/nova/2018/nova.2018-07-12-14.00.log.html#l-71
[2] 
https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/vgpu-rocky.html
[3] 
https://review.openstack.org/#/q/topic:bp/vgpu-rocky+(status:open+OR+status:merged)

-- 

Thanks,

Matt