On Oct 18, 2019, at 12:06 PM, Matthew Thode <mthode@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@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/b8ae681b37eec617736ac4a507e9... [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