I can do it on xenserver side, although keep old inv in compute node rp looks weird to me(it just work for one case: upgrade)...
-----Original Message----- From: Eric Fried [mailto:openst...@fried.cc] Sent: Thursday, May 31, 2018 9:54 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers 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#L37 >> 5) 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