<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 31, 2018 at 3:54 PM, Eric Fried <span dir="ltr"><<a href="mailto:openstack@fried.cc" target="_blank">openstack@fried.cc</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This seems reasonable, but...<br>
<span class=""><br>
On 05/31/2018 04:34 AM, Balázs Gibizer wrote:<br>
> <br>
> <br>
> On Thu, May 31, 2018 at 11:10 AM, Sylvain Bauza <<a href="mailto:sbauza@redhat.com">sbauza@redhat.com</a>> wrote:<br>
>>><br>
>><br>
>> After considering the whole approach, discussing with a couple of<br>
>> folks over IRC, here is what I feel the best approach for a seamless<br>
>> upgrade :<br>
>>  - VGPU inventory will be kept on root RP (for the first type) in<br>
>> Queens so that a compute service upgrade won't impact the DB<br>
>>  - during Queens, operators can run a DB online migration script (like<br>
</span>-------------^^^^^^<br>
Did you mean Rocky?<br></blockquote><div><br><br></div><div>Oops, yeah of course. Queens > Rocky. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
>> the ones we currently have in<br>
>> <a href="https://github.com/openstack/nova/blob/c2f42b0/nova/cmd/manage.py#L375" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>nova/blob/c2f42b0/nova/cmd/<wbr>manage.py#L375</a>) that<br>
>> will create a new resource provider for the first type and move the<br>
>> inventory and allocations to it.<br>
>>  - it's the responsibility of the virt driver code to check whether a<br>
>> child RP with its name being the first type name already exists to<br>
>> know whether to update the inventory against the root RP or the child RP.<br>
>><br>
>> Does it work for folks ?<br>
> <br>
> +1 works for me<br>
> gibi<br>
> <br>
>> PS : we already have the plumbing in place in nova-manage and we're<br>
>> still managing full Nova resources. I know we plan to move Placement<br>
>> out of the nova tree, but for the Rocky timeframe, I feel we can<br>
>> consider nova-manage as the best and quickiest approach for the data<br>
>> upgrade.<br>
>><br>
>> -Sylvain<br>
>><br>
>><br>
> <br>
> <br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>