[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