first pass at updating OADP versions #1594
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: weshayutin The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@weshayutin: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
There was a problem hiding this comment.
While supporting a specific version of OADP on a given OCP version makes sense and should ease the burden in this area...
What does the upgrade path look like for supporting only a single version of OADP for a given OCP version? Is ${OADP.Next} shipped to OCP version-1 or is ${OADP.Current} shipped to OCP version+1?
| # OADP Partner Information | ||
|
|
||
| ## Important Announcement: Version Support Changes | ||
| Starting in 2024, OADP will implement a streamlined version support policy. Red Hat will support only one version of OADP per OpenShift version to ensure better stability and maintainability. |
There was a problem hiding this comment.
While official OADP support position may be what we're aiming to address here, does this accommodate circumstances where an existing dependency relationship already exists. For example, OADP 1.4 may be the officially supported version on, say, v4.15, but a user of MTC 1.7 requires OADP 1.0 to move from legacy OCP (v3.11). I understand the simultaneous use/installation of different versions of OADP on-cluster is definitely not supported, but (acknowledging no other version of OADP is installed) will there continue to exist support for OADP 1.0 (under MTC 1.7)?
There was a problem hiding this comment.
I suspect this may be the case for MTC until such time as they're aged out after this [proposed] change. MTC 1.8 already follows along with the supported versions of OADP, so it shouldn't be a concern there. The concern here is specifically MTC 1.7's dependency on OADP 1.0 in support of legacy migrations from v3.11 to <=v4.16 clusters. Currently, 1.7 is expected to remain available/supported until 2025-JUL according to .../support/policy/...:
There was a problem hiding this comment.
Any such existing relationship with other/partner products to consider?
There was a problem hiding this comment.
I think the version must be clearly defined. One major version, there are still updates allowed. I know this is mostly understandable by everyone, but needs to be stated.
| ## Important Announcement: Version Support Changes | ||
| Starting in 2024, OADP will implement a streamlined version support policy. Red Hat will support only one version of OADP per OpenShift version to ensure better stability and maintainability. |
There was a problem hiding this comment.
| ## Important Announcement: Version Support Changes | |
| Starting in 2024, OADP will implement a streamlined version support policy. Red Hat will support only one version of OADP per OpenShift version to ensure better stability and maintainability. | |
| ## Important Announcement: Version Support Changes | |
| Starting in 2025, OADP will implement a streamlined version support policy. Red Hat will support only one version of OADP per OpenShift version to ensure better stability and maintainability. |
Given the current time of year and this PR's recent creation, should this be 2025?
This probably isn't the best course given the shortcomings discovered with OADP 1.3 on OCP v4.16. If anything, " |
Why the changes were made
How to test the changes made
read it!