[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