[nova] FFU : When should we remove reshape support for a feature ?
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.rackcd...
It may be worth taking into account that we had a work item to write a FFU hook for this, but it was never done. http://lists.openstack.org/pipermail/openstack-dev/2018-October/136110.html http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004204.htm... efried_stirs_pot_from_afar On 3/31/20 7:35 AM, Sylvain Bauza wrote:
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.rackcd...
On Tue, Mar 31, 2020 at 4:43 PM Eric Fried <openstack@fried.cc> wrote:
It may be worth taking into account that we had a work item to write a FFU hook for this, but it was never done.
http://lists.openstack.org/pipermail/openstack-dev/2018-October/136110.html
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004204.htm...
OK, I already provided my thoughts for the virtual PTG etherpad in https://etherpad.openstack.org/p/nova-victoria-ptg I'll add those links and see whether I can volunteer for it in the next cycle. -S efried_stirs_pot_from_afar
On 3/31/20 7:35 AM, Sylvain Bauza wrote:
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.rackcd...
On Tue, Mar 31, 2020 at 8:38 AM Sylvain Bauza <sbauza@redhat.com> wrote:
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.
I think that's more than enough from an operators POV and in terms of "making the lives of our devs" easier POV.
-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.rackcd...
-- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. https://vexxhost.com
participants (3)
-
Eric Fried
-
Mohammed Naser
-
Sylvain Bauza