[openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers
naichuan.sun at citrix.com
Thu May 31 14:14:48 UTC 2018
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)...
From: Eric Fried [mailto:openstack at fried.cc]
Sent: Thursday, May 31, 2018 9:54 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at 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 <sbauza at 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
Did you mean Rocky?
>> the ones we currently have in
>> 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
>> 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
> ____ OpenStack Development Mailing List (not for usage questions)
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev