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

Eric Fried openstack at fried.cc
Tue Mar 31 14:29:00 UTC 2020

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.



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.rackcdn.com/715489/1/check/nova-tox-functional-py36/481510f/testr_results.html

More information about the openstack-discuss mailing list