Open Stack

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: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 
>> (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-request at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev