On Thu, May 31, 2018 at 3:54 PM, Eric Fried <openst...@fried.cc> wrote:
> This seems reasonable, but... > > On 05/31/2018 04:34 AM, Balázs Gibizer wrote: > > > > > > On Thu, May 31, 2018 at 11:10 AM, Sylvain Bauza <sba...@redhat.com> > wrote: > >>> > >> > >> After considering the whole approach, discussing with a couple of > >> folks over IRC, here is what I feel the best approach for a seamless > >> upgrade : > >> - VGPU inventory will be kept on root RP (for the first type) in > >> Queens so that a compute service upgrade won't impact the DB > >> - during Queens, operators can run a DB online migration script (like > -------------^^^^^^ > Did you mean Rocky? > Oops, yeah of course. Queens > Rocky. > > >> the ones we currently have in > >> https://github.com/openstack/nova/blob/c2f42b0/nova/cmd/manage.py#L375) > that > >> will create a new resource provider for the first type and move the > >> inventory and allocations to it. > >> - it's the responsibility of the virt driver code to check whether a > >> child RP with its name being the first type name already exists to > >> know whether to update the inventory against the root RP or the child > RP. > >> > >> Does it work for folks ? > > > > +1 works for me > > gibi > > > >> PS : we already have the plumbing in place in nova-manage and we're > >> still managing full Nova resources. I know we plan to move Placement > >> out of the nova tree, but for the Rocky timeframe, I feel we can > >> consider nova-manage as the best and quickiest approach for the data > >> upgrade. > >> > >> -Sylvain > >> > >> > > > > > > ____________________________________________________________ > ______________ > > 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 > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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
