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

Tom Barron tpb at dyncloud.net
Fri Apr 12 13:52:35 UTC 2019


On 12/04/19 12:47 +1000, Tony Breeds wrote:
>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?

Right, or some support person told them some magic.

>
>Yours Tony.
>
>[1] or probably 5.1.0 as a signal to operators

Agree that 5.1.0 makes sense, thanks.




More information about the openstack-discuss mailing list