[nova] FFU : When should we remove reshape support for a feature ?

Sylvain Bauza sbauza at redhat.com
Tue Mar 31 12:35:02 UTC 2020


Hola,

In Stein, I provided a new feature [1] that was checking inventories from
multiple children resource providers (RP). Since in Rocky, those
inventories were only on the root RP, I had to provide both :
 #1 : an upgrade support for RPs that were not having a parent RP (that was
the case of Stein compute nodes) [2]
 #2 : a reshape method in the libvirt driver for moving allocations from a
root RP to children RPs [3]

Now, we're in the Ussuri timeframe and as I was usually doing, I removed
the upgrade support (in #1) since we're 100% sure that all compute nodes
are either Train or Ussuri [4]

This is cool, but now the reshape code I wrote for #2 no longer works
(which is normal, since the 'non-Stein' support was removed) [5]

Soooooo. Can I also then remove the reshape support ? That would mean that
upgrading from Rocky to Train would work, but Rocky to Ussuri wouldn't. I'm
personally OK with this, but I guess other people could have concerns with.

Do we have any consensus about how longer we would support a reshape ? I
think honestly that a 3-releases time window is enough but I can hear some
disagreements about this strawman proposal. If so, please voice.

-Sylvain

[1] https://blueprints.launchpad.net/nova/+spec/vgpu-stein
[2] https://review.opendev.org/#/c/636591/
[3] https://review.opendev.org/#/c/599208/
[4] https://review.opendev.org/#/c/715489/
[5]
https://541e2403478ac154d5eb-056bfb946e355d1a1a86dc411a70c5ec.ssl.cf2.rackcdn.com/715489/1/check/nova-tox-functional-py36/481510f/testr_results.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200331/6071925d/attachment-0001.html>


More information about the openstack-discuss mailing list