Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 2029539

Summary: python-sushy library tracking is pinned to a version, not synced nor tracking stable branch [16.2]
Product: Red Hat OpenStack Reporter: Julia Kreger <jkreger>
Component: python-sushyAssignee: OSP Team <rhos-maint>
Status: CLOSED NOTABUG QA Contact: Arik Chernetsky <achernet>
Severity: high Docs Contact:
Priority: unspecified    
Version: 16.2 (Train)CC: achernet, amoralej, jschluet, rhos-maint, sbaker
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 2029532 Environment:
Last Closed: 2022-01-10 15:12:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Comment 1 Jon Schlueter 2021-12-06 17:43:27 UTC
Description of problem:

Downstream package tracking is based upon a fixed release version of python-sushy, in particular for Train based releases of OpenStack, the version is locked to the very last upstream release of the python-sushy library.

While upstream, we're no longer able to cut new releases for the Train version of the library, we do occasionally land fixes upstream which we need to get downstream or have cases which would have been completely prevented if we were tracking the stable branch upstream.

At present, python-sushy 2.0.5 is what is shipped however we need to be able to pull down patches to stable branches and not have them overwritten upon the next sync. Two patches exist which we would like to ultimately merge into 16.1 and 16.2 OSP releases, requiring the packaging pipeline to be updated.

Comment 2 Steve Baker 2021-12-07 20:36:23 UTC
Assigning to PCD, its our component but we can't make this change

Comment 3 Alfredo Moralejo 2022-01-03 10:23:11 UTC
For libraries which are in upper-constraints.txt we follow what is pinned there, in this case 2.0.5:

https://github.com/openstack/requirements/blob/stable/train/upper-constraints.txt#L437

So, there are two ways of managing this:

1. Create a new release for sushy in stable/train and update u-c. That will trigger an automated bump in rdoinfo and a new release in rdo.
2. Explicitely pin python-sushy to stable/train branch in rdoinfo. In that case a review from the maintainer is required

Let me know if you have doubts about this

Comment 4 Julia Kreger 2022-01-03 15:09:33 UTC
(In reply to Alfredo Moralejo from comment #3)
> For libraries which are in upper-constraints.txt we follow what is pinned
> there, in this case 2.0.5:
> 
> https://github.com/openstack/requirements/blob/stable/train/upper-
> constraints.txt#L437
> 

Indeed, AIUI, we don't rely upon this for our downstream packaging.

> So, there are two ways of managing this:
> 
> 1. Create a new release for sushy in stable/train and update u-c. That will
> trigger an automated bump in rdoinfo and a new release in rdo.

Indeed. The branch is in extended maintenance meaning no new releases are permitted.

Hence why I filed this request to allow us to similarly track a downstream branch as we do with service projects.

> 2. Explicitely pin python-sushy to stable/train branch in rdoinfo. In that
> case a review from the maintainer is required
> 

This seems to be the only viable option to move forward and get the required fixes into the product and keep them there without possibly creating regressions.

> Let me know if you have doubts about this