[ironic][release][stable] Ironic Train release can be broken due to entry in driver-requirements.txt
Doug Hellmann
doug at doughellmann.com
Fri Oct 18 17:36:37 UTC 2019
> On Oct 18, 2019, at 12:06 PM, Matthew Thode <mthode at mthode.org> wrote:
>
> On 19-10-18 12:19:12, Dmitry Tantsur wrote:
>> Hi all,
>>
>> I think we should update global-requirement (on master and train) to
>> exclude sushy 1.9.0, like
>>
>> sushy!=1.9.0
>>
>> Since train has >=1.9.0 currently, it will be a good excuse to change it to
>> 2.0.0.
>>
>> I'll leave the final word to the stable team though.
>>
>> Dmitry
>>
>> On Wed, Oct 16, 2019 at 3:17 AM <Richard.Pioso at dell.com> wrote:
>>
>>> Hi,
>>>
>>> The Ironic Train release can be broken due to an entry in its
>>> driver-requirements.txt. driver-requirements.txt defines a dependency on
>>> the sushy package [1] which can be satisfied by version 1.9.0.
>>> Unfortunately, that version contains a few bugs which prevent Ironic from
>>> being able to manage Dell EMC and perhaps other vendors' bare metal
>>> hardware with its Redfish hardware type (driver). The fixes to them
>>> [2][3][4] were merged into master before the creation of stable/train.
>>> Therefore, they are available on stable/train and in the last sushy release
>>> created during the Train cycle, 2.0.0, the only other version which can
>>> satisfy the dependency today. However, consumers -- packagers, operators,
>>> and users -- could, fighting time constraints or lacking solid visibility
>>> into Ironic, package or install Ironic with sushy 1.9.0 to satisfy the
>>> dependency, but, in so doing, unknowingly render the package or
>>> installation severely broken.
>>>
>>> A change [5] has been proposed as part of a prospective solution to this
>>> issue. It creates a new release of sushy from the change which fixes the
>>> first bug [2]. Review comments [6] discuss basing the new release on a more
>>> recent stable/train change to pick up other bug fixes and, less
>>> importantly, backward compatible feature modifications and enhancements
>>> which merged before the change from which 2.0.0 was created. Backward
>>> compatible feature modifications and enhancements are interspersed in time
>>> among the bug fixes. Once a new release is available, the sushy entry in
>>> driver-requirements.txt on stable/train would be updated. However,
>>> apparently, the stable branch policy prevents releases from being done at a
>>> point earlier than the last release within a given cycle [6], which was
>>> 2.0.0.
>>>
>>> Another possible resolution which comes to mind is to change the
>>> definition of the sushy dependency in driver-requirements.txt [1] from
>>> "sushy>=1.9.0" to "sushy>=2.0.0".
>>>
>>> Does anyone have a suggestion on how to proceed?
>>>
>>> Thank you,
>>> Rick
>>>
>>>
>>> [1]
>>> https://opendev.org/openstack/ironic/src/commit/b8ae681b37eec617736ac4a507e9a8b3a19e8a58/driver-requirements.txt#L14
>>> [2] https://review.opendev.org/#/c/666253/
>>> [3] https://review.opendev.org/#/c/668936/
>>> [4] https://review.opendev.org/#/c/669889/
>>> [5] https://review.opendev.org/#/c/688551/
>>> [6]
>>> https://review.opendev.org/#/c/688551/1/deliverables/train/sushy.yaml@14
>>>
>>>
>>>
>
> Excluding known bad versions to efectively update the minimum constraint
> IS allowed by policy as far as I know (from a reqs team perspective).
> So this sgtm.
>
> --
> Matthew Thode
I agree, we should exclude the bad version in constraints. But we shouldn’t *only* do that as a way to side-step our other policies and raise the minimum version.
We don’t typically change the minimum version of a dependency just because of a bug fix. In this case, though, we have what sounds like a significant incompatibility, and IIRC we have allowed updates in the past to resolve those problems.
In this case, I think it’s safe to call the current dependency setting for sushy in the Ironic stable/train branch a bug (in ironic) and to allow that minimum to be updated without considering it a break in the stable policy, because Ironic is broken without the update.
Normally we would want the new release after the dependency update to be a feature update (the Y in X.Y.Z) because we haven’t added an incompatible dependency or changed the API but we have updated the dependencies. So, I think that means we will need an Ironic 2.1.0 release off of stable/train after the dependency is fixed (rather than 2.0.1 for a bug fix or 3.0.0 for a major update).
Doug
More information about the openstack-discuss
mailing list