[dev][stable][release][manila] Should we revert these stable branch backports?

Tony Breeds tony at bakeyournoodle.com
Fri Apr 12 02:47:09 UTC 2019


On Wed, Mar 27, 2019 at 08:56:54AM -0400, Tom Barron wrote:
> In manila we recently merged backports of a change [1] that aims
> to fix up faulty configuration option deprecations in the
> Dell-EMC VMAX driver.  The question at hand is whether (a) we
> should revert these backports on the grounds that the
> deprecations were faulty and therefore are only effective from
> Stein forwards, or whether (b) the deprecations actually worked
> and took effect back when Ocata was the development branch but
> had faults that should be corrected all the way back to Pike
> before it goes EM.

Thanks for writing this all up Tom.  I'm sorry it's taken me so long to
get to it.
 
> I think (b) is the correct answer but let's check.
> 
> On Jan 10 2017 a review [2] merged that deprecated generic
> Dell-EMC driver options in favor of model-specific options [2].
> There were two models at the time, Unity and VNX.  This change
> was in itself unproblematic.
> 
> On Jan 24 2017 a review [3] merged that introduced a third
> Dell-EMC model, VMAX.  This new code introduced VMAX specific
> options, consistent with the deprecation of the generic Dell-EMC
> options.  However it had two problems which review [1] corrects.
> When it defined the new VMAX-specific options it failed to
> indicate the corresponding old generic options via
> 'deprecated_name' [4].  Worse, the code that consumed the options
> actually looked for the old generic 'emc_interface_ports' option
> instead of the new 'vmax_ethernet_ports' option.  The only way to
> set a value for this option was to use its deprecated
> form.

So someone that is using the VMAX driver from 5.0.3 has set
emc_interface_ports in the config.  Assuming we don't revert and release
5.0.4[1], that same config file will continue to work but there will now be
a deprecation warning in the logs.

The VMAX user probably had to look at the code to workout that the
config sample was out of sync with the code?

Yours Tony.

[1] or probably 5.1.0 as a signal to operators
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/12da72f8/attachment.sig>


More information about the openstack-discuss mailing list