<div dir="ltr"><div dir="ltr">On Wed, Oct 16, 2019 at 10:27 AM Julia Kreger <<a href="mailto:juliaashleykreger@gmail.com">juliaashleykreger@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm okay if we just change driver-requirements.txt at this point and<br>
go ahead and cut new release for ironic. I actually feel like we<br>
should have bumped driver-requirements.txt after releasing sushy 2.0.0<br>
anyway.<br></blockquote><div><br></div><div>Yeah, I think I agree here. The options I see are:</div><div><br></div><div>* Ironic train depends on 2.0.0. This breaks stable policy.</div><div>* We release 1.10.0 and depend on that. This breaks stable and release team policy.</div><div>* We keep our dependencies the same and document that 1.9.0 is broken. This breaks no policy.</div><div><br></div><div>The last option follows the letter of the law best, but doesn't actually help our users. If they need to use 2.0.0 to have a working system anyway, then the effect on users is the same as the first option, but in a backwards way.</div><div><br></div><div>Let's just bring ironic to 2.0.0 and fix any breakage that comes with it.</div><div><br></div><div>// jim</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The bottom line is we need to focus on the user experience of using<br>
the software. For ironic, if a vendor's class of gear just doesn't<br>
work with a possible combination, then we should try and take the<br>
least resistance and greatest impact path to remedying that situation.<br>
<br>
As for the "prevents a prior release" portion of policy, That is<br>
likely written for the projects that perform release candidates and<br>
not projects that do not. At least, that is my current feeling. That<br>
seems super counter-intuitive for ironic's release model if there is a<br>
major bug that is identified that needs to be fixed in the software we<br>
have shipped.<br>
<br>
-Julia<br>
<br>
On Tue, Oct 15, 2019 at 6:21 PM <<a href="mailto:Richard.Pioso@dell.com" target="_blank">Richard.Pioso@dell.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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".<br>
><br>
> Does anyone have a suggestion on how to proceed?<br>
><br>
> Thank you,<br>
> Rick<br>
><br>
><br>
> [1] <a href="https://opendev.org/openstack/ironic/src/commit/b8ae681b37eec617736ac4a507e9a8b3a19e8a58/driver-requirements.txt#L14" rel="noreferrer" target="_blank">https://opendev.org/openstack/ironic/src/commit/b8ae681b37eec617736ac4a507e9a8b3a19e8a58/driver-requirements.txt#L14</a><br>
> [2] <a href="https://review.opendev.org/#/c/666253/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/666253/</a><br>
> [3] <a href="https://review.opendev.org/#/c/668936/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/668936/</a><br>
> [4] <a href="https://review.opendev.org/#/c/669889/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/669889/</a><br>
> [5] <a href="https://review.opendev.org/#/c/688551/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/688551/</a><br>
> [6] <a href="https://review.opendev.org/#/c/688551/1/deliverables/train/sushy.yaml@14" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/688551/1/deliverables/train/sushy.yaml@14</a><br>
><br>
><br>
<br>
</blockquote></div></div>