Open Stack

> On Oct 18, 2019, at 1:36 PM, Doug Hellmann <doug at doughellmann.com> wrote:
> 
> 
> 
>> 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
> 

Sorry, ignore my version number math there. I picked up the sushy version number rather than the ironic version number. Just do a feature release of ironic on stable/train, whatever the right number is.

Doug