<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 31, 2020 at 4:43 PM Eric Fried <openstack@fried.cc> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It may be worth taking into account that we had a work item to write a <br>
FFU hook for this, but it was never done.<br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2018-October/136110.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2018-October/136110.html</a><br>
<a href="http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004204.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004204.html</a><br>
<br></blockquote><div><br></div><div>OK, I already provided my thoughts for the virtual PTG etherpad in <a href="https://etherpad.openstack.org/p/nova-victoria-ptg">https://etherpad.openstack.org/p/nova-victoria-ptg</a></div><div>I'll add those links and see whether I can volunteer for it in the next cycle.</div><div><br></div><div>-S</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
efried_stirs_pot_from_afar<br>
<br>
On 3/31/20 7:35 AM, Sylvain Bauza wrote:<br>
> Hola,<br>
> <br>
> In Stein, I provided a new feature [1] that was checking inventories <br>
> from multiple children resource providers (RP). Since in Rocky, those <br>
> inventories were only on the root RP, I had to provide both :<br>
>   #1 : an upgrade support for RPs that were not having a parent RP (that <br>
> was the case of Stein compute nodes) [2]<br>
>   #2 : a reshape method in the libvirt driver for moving allocations <br>
> from a root RP to children RPs [3]<br>
> <br>
> Now, we're in the Ussuri timeframe and as I was usually doing, I removed <br>
> the upgrade support (in #1) since we're 100% sure that all compute nodes <br>
> are either Train or Ussuri [4]<br>
> <br>
> This is cool, but now the reshape code I wrote for #2 no longer works <br>
> (which is normal, since the 'non-Stein' support was removed) [5]<br>
> <br>
> Soooooo. Can I also then remove the reshape support ? That would mean <br>
> that upgrading from Rocky to Train would work, but Rocky to Ussuri <br>
> wouldn't. I'm personally OK with this, but I guess other people could <br>
> have concerns with.<br>
> <br>
> Do we have any consensus about how longer we would support a reshape ? I <br>
> think honestly that a 3-releases time window is enough but I can hear <br>
> some disagreements about this strawman proposal. If so, please voice.<br>
> <br>
> -Sylvain<br>
> <br>
> [1] <a href="https://blueprints.launchpad.net/nova/+spec/vgpu-stein" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/nova/+spec/vgpu-stein</a><br>
> [2] <a href="https://review.opendev.org/#/c/636591/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/636591/</a><br>
> [3] <a href="https://review.opendev.org/#/c/599208/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/599208/</a><br>
> [4] <a href="https://review.opendev.org/#/c/715489/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/715489/</a><br>
> [5] <br>
> <a href="https://541e2403478ac154d5eb-056bfb946e355d1a1a86dc411a70c5ec.ssl.cf2.rackcdn.com/715489/1/check/nova-tox-functional-py36/481510f/testr_results.html" rel="noreferrer" target="_blank">https://541e2403478ac154d5eb-056bfb946e355d1a1a86dc411a70c5ec.ssl.cf2.rackcdn.com/715489/1/check/nova-tox-functional-py36/481510f/testr_results.html</a><br>
> <br>
<br>
</blockquote></div></div>