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?
>> 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
