[openstack-dev] [nova] What do we lose if the reshaper stuff doesn't land in Rocky?
jaypipes at gmail.com
Thu Jul 12 14:47:00 UTC 2018
Let's just get the darn thing done in Rocky. I will have the DB work up
for review today.
On 07/12/2018 10:45 AM, Matt Riedemann wrote:
> Continuing the discussion from the nova meeting today , 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. 
> Looking at the status of the vgpu-rocky blueprint , 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?
More information about the OpenStack-dev