[ironic][release][stable] Ironic Train release can be broken due to entry in driver-requirements.txt
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
I'm okay if we just change driver-requirements.txt at this point and go ahead and cut new release for ironic. I actually feel like we should have bumped driver-requirements.txt after releasing sushy 2.0.0 anyway. The bottom line is we need to focus on the user experience of using the software. For ironic, if a vendor's class of gear just doesn't work with a possible combination, then we should try and take the least resistance and greatest impact path to remedying that situation. As for the "prevents a prior release" portion of policy, That is likely written for the projects that perform release candidates and not projects that do not. At least, that is my current feeling. That seems super counter-intuitive for ironic's release model if there is a major bug that is identified that needs to be fixed in the software we have shipped. -Julia On Tue, Oct 15, 2019 at 6:21 PM <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
On Wed, Oct 16, 2019 at 10:27 AM Julia Kreger <juliaashleykreger@gmail.com> wrote:
I'm okay if we just change driver-requirements.txt at this point and go ahead and cut new release for ironic. I actually feel like we should have bumped driver-requirements.txt after releasing sushy 2.0.0 anyway.
Yeah, I think I agree here. The options I see are: * Ironic train depends on 2.0.0. This breaks stable policy. * We release 1.10.0 and depend on that. This breaks stable and release team policy. * We keep our dependencies the same and document that 1.9.0 is broken. This breaks no policy. 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. Let's just bring ironic to 2.0.0 and fix any breakage that comes with it. // jim
The bottom line is we need to focus on the user experience of using the software. For ironic, if a vendor's class of gear just doesn't work with a possible combination, then we should try and take the least resistance and greatest impact path to remedying that situation.
As for the "prevents a prior release" portion of policy, That is likely written for the projects that perform release candidates and not projects that do not. At least, that is my current feeling. That seems super counter-intuitive for ironic's release model if there is a major bug that is identified that needs to be fixed in the software we have shipped.
-Julia
On Tue, Oct 15, 2019 at 6:21 PM <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
Julia, I am for it also. But with Train just released, from Sean email, how does it get into Train? -----Original Message----- From: Julia Kreger <juliaashleykreger@gmail.com> Sent: Wednesday, October 16, 2019 9:27 AM To: Pioso, Richard Cc: openstack-discuss Subject: Re: [ironic][release][stable] Ironic Train release can be broken due to entry in driver-requirements.txt [EXTERNAL EMAIL] I'm okay if we just change driver-requirements.txt at this point and go ahead and cut new release for ironic. I actually feel like we should have bumped driver-requirements.txt after releasing sushy 2.0.0 anyway. The bottom line is we need to focus on the user experience of using the software. For ironic, if a vendor's class of gear just doesn't work with a possible combination, then we should try and take the least resistance and greatest impact path to remedying that situation. As for the "prevents a prior release" portion of policy, That is likely written for the projects that perform release candidates and not projects that do not. At least, that is my current feeling. That seems super counter-intuitive for ironic's release model if there is a major bug that is identified that needs to be fixed in the software we have shipped. -Julia On Tue, Oct 15, 2019 at 6:21 PM <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/b8ae681b37eec617736ac4 a507e9a8b3a19e8a58/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
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
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
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
On Oct 18, 2019, at 1:36 PM, Doug Hellmann <doug@doughellmann.com> wrote:
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
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
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.
+1, I think this should be fine for a stable backport. The feature version bump will be a good indication to anyone picking it up that something (semi)significant has changed, so they should pay attention. Might be a good idea to include a release note with the change to make sure it is called out in a way that consumers will be aware of the change.
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
Since there seems to be agreement, the change to require the bump has been posted to master branch[0]. Once backported and merged to the stable branch we can go ahead and release 13.1.0. -Julia [0]: https://review.opendev.org/#/c/687983/ On Fri, Oct 18, 2019 at 12:23 PM Sean McGinnis <sean.mcginnis@gmx.com> wrote:
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.
+1, I think this should be fine for a stable backport.
The feature version bump will be a good indication to anyone picking it up that something (semi)significant has changed, so they should pay attention.
Might be a good idea to include a release note with the change to make sure it is called out in a way that consumers will be aware of the change.
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
On Fri, Oct 18, 2019 at 11:06:09AM -0500, Matthew Thode wrote:
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.
This is not allowed with the stable policy. The only policy exception fro raising a minim requirement is because of a security issue. I think The VMT classification was A or B? but I'm fuzzy on that. I say this only to clarify the reasons for allowing fixes like this, not as a statement about this specific case. In this specific case we have: $ tools/grep-all.sh sushy Requirements ------------ 1.2.0-2605-g9806c0bb : sushy # Apache-2.0 origin/master : sushy # Apache-2.0 origin/stable/train : sushy # Apache-2.0 <snip> Constraints ----------- 1.2.0-2605-g9806c0bb : sushy===2.0.0 origin/master : sushy===2.0.0 origin/stable/train : sushy===2.0.0 <snip> $ So *iff* distros (Debian, UCA, RDO, OpenSuse) are already packaging 2.0.0 for *train* I'm okay with plan to: Master: * Exclude 1.9.0 from global-requirements * Bump the acceptable lower-constraints in ironic Train: * Backport the above changes * release ironic X.(y+1).0 I don't have the where-with-all to do the checking right now, but if someone else does I'll sign off on things (hint hint ;P) If the pre-condition isn't met we can investigate the impact of meeting it vs the UX for the train release. I'm aware we want to get this fixed ASAP Yours Tony.
Debian, RDO Project, and OpenSuse Train packaging pipelines show 2.0.0. UCA doesn't seem to have train packaging at this point. -Julia On Fri, Oct 18, 2019 at 4:23 PM Tony Breeds <tony@bakeyournoodle.com> wrote:
On Fri, Oct 18, 2019 at 11:06:09AM -0500, Matthew Thode wrote:
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.
This is not allowed with the stable policy. The only policy exception fro raising a minim requirement is because of a security issue. I think The VMT classification was A or B? but I'm fuzzy on that.
I say this only to clarify the reasons for allowing fixes like this, not as a statement about this specific case.
In this specific case we have:
$ tools/grep-all.sh sushy
Requirements ------------ 1.2.0-2605-g9806c0bb : sushy # Apache-2.0 origin/master : sushy # Apache-2.0 origin/stable/train : sushy # Apache-2.0 <snip>
Constraints ----------- 1.2.0-2605-g9806c0bb : sushy===2.0.0 origin/master : sushy===2.0.0 origin/stable/train : sushy===2.0.0 <snip> $
So *iff* distros (Debian, UCA, RDO, OpenSuse) are already packaging 2.0.0 for *train* I'm okay with plan to:
Master: * Exclude 1.9.0 from global-requirements * Bump the acceptable lower-constraints in ironic Train: * Backport the above changes * release ironic X.(y+1).0
I don't have the where-with-all to do the checking right now, but if someone else does I'll sign off on things (hint hint ;P)
If the pre-condition isn't met we can investigate the impact of meeting it vs the UX for the train release. I'm aware we want to get this fixed ASAP
Yours Tony.
On Fri, Oct 18, 2019 at 05:52:10PM -0700, Julia Kreger wrote:
Debian, RDO Project, and OpenSuse Train packaging pipelines show 2.0.0. UCA doesn't seem to have train packaging at this point.
UCA for train is here: https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/train-staging it doesn't seem to have a python-sushy package, which means it's getting the one from bionic[1] which is already violating the lower-constraint for ironic Even 'eon' is 1.8.1? I've added James to CC to see if he can clarify my thinking and or arrange to update sushy. Tony. [1] https://packages.ubuntu.com/search?keywords=python-sushy
On Fri, Oct 18, 2019 at 9:33 PM Tony Breeds <tony@bakeyournoodle.com> wrote:
On Fri, Oct 18, 2019 at 05:52:10PM -0700, Julia Kreger wrote:
Debian, RDO Project, and OpenSuse Train packaging pipelines show 2.0.0. UCA doesn't seem to have train packaging at this point.
UCA for train is here:
https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/train-staging it doesn't seem to have a python-sushy package, which means it's getting the one from bionic[1] which is already violating the lower-constraint for ironic
Even 'eon' is 1.8.1?
I've added James to CC to see if he can clarify my thinking and or arrange to update sushy.
If we need to update sushy in UCA anyway, sounds like we could probably go straight to 2.0.0 and then go ahead and do the requirements update dance mentioned upthread? // jim
Tony. [1] https://packages.ubuntu.com/search?keywords=python-sushy
On Mon, Oct 21, 2019 at 10:43:39AM -0400, Jim Rollenhagen wrote:
If we need to update sushy in UCA anyway, sounds like we could probably go straight to 2.0.0 and then go ahead and do the requirements update dance mentioned upthread?
Yup totally. I haven't seen anything from James/Ubuntu that indicates they're cool with this. Yours Tony.
On 10/16/19 2:55 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.
At least in Debian, sushy 2.0.0 is included in the Train release (sushy 2.0.0 was uploaded on the 26th of September). I don't know for other distros.
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?
I'm not sure if I understand you correctly. Is sushy 2.0.0 enough? Or should I expect newer tags coming soon? Thomas Goirand (zigo)
On Sat, Oct 19, 2019 at 1:16 PM Thomas Goirand <zigo@debian.org> 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
On 10/16/19 2:55 AM, Richard.Pioso@dell.com wrote: 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.
At least in Debian, sushy 2.0.0 is included in the Train release (sushy 2.0.0 was uploaded on the 26th of September). I don't know for other distros.
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?
I'm not sure if I understand you correctly. Is sushy 2.0.0 enough? Or should I expect newer tags coming soon?
Yes, sushy 2.0.0 works as expected. Of course, there may be future bugfix releases from the train branch, but we don't have any planned right now. // jim
Thomas Goirand (zigo)
participants (10)
-
Arkady.Kanevsky＠dell.com
-
Dmitry Tantsur
-
Doug Hellmann
-
Jim Rollenhagen
-
Julia Kreger
-
Matthew Thode
-
Richard.Pioso＠dell.com
-
Sean McGinnis
-
Thomas Goirand
-
Tony Breeds