Let's just get the darn thing done in Rocky. I will have the DB work up
for review today.
-jay
On 07/12/2018 10:45 AM, Matt Riedemann wrote:
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)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
