Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

first pass at updating OADP versions #1594

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions PARTNERS.md
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would move this to docs folder

Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
# 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/...:
image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any such existing relationship with other/partner products to consider?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +3 to +4
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## 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?


## Version Mapping

### Current and Planned Supported Versions
| OpenShift Version | OADP Version | Velero Version |
|-------------------|--------------|----------------|
| 4.22 | 1.6 | v1.18 |
| 4.21 | 1.6 | v1.18 |
| 4.20 | 1.5 | v1.16 |
| 4.19 | 1.5 | v1.16 |
| 4.18 | 1.4 | v1.14 |
| 4.17 | 1.4 | v1.14 |
| 4.16 | 1.4 | v1.14 |
| 4.15 | 1.3, 1.4 | v1.12, v1.14 |
| 4.14 | 1.3, 1.4 | v1.12, v1.14 |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there are specific patch versions that are considered good for each OCP version?

example I assume 1.4.0+ is ok to be used in 4.16, but for 4.18, do we need like 1.4.4+ for example?



### Future Release Planning
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we have only one table? example

OpenShift Version OADP Version Velero Version Estimated Release Timeline
4.22 1.6 v1.18 Q1 2027
4.21 1.6 v1.18 Q3 2026
4.20 1.5 v1.16 Q1 2026
4.19 1.5 v1.16 Q3 2025
4.18 1.4 v1.14 Q1 2025
4.17 1.4 v1.14 released

| OpenShift Version | Planned OADP Version | Estimated Release Timeline |
|-------------------|---------------------|-------------------------|
| 4.18 | 1.4 | Q1 2025 |
| 4.19 | 1.5 | Q3 2025 |
| 4.20 | 1.5 | Q1 2026 |
| 4.21 | 1.6 | Q3 2026 |
| 4.22 | 1.6 | Q1 2027 |

## Impact on Partners
- Partners must align their integration testing with the specific OADP version corresponding to their target OpenShift version
- Unreleased OADP builds are available via the branches of this oadp-operator repository. The next release will be available for install via the `master` branch until such time the next release branch is created, the `oadp-1.5` branch will be made available for install.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unreleased OADP builds are available via development branches of this repository. The next release will be available for install via the oadp-<major>.<minor> branch. Until the next release branch is created, the master branch contains next release code.


## Action Items for Partners
1. Update your test matrices to reflect the new version pairing strategy
2. Determine if installing development builds from the openshift git repository is acceptable for testing and certification efforts. If a downstream build is required, please contact your Red Hat partner manager for guidance.
3. Update documentation to reflect supported version combinations
4. Communicate these changes to customers using your backup solutions


## Additional Resources
- [Red Hat Partner Program](https://connect.redhat.com/)
- [Contact Red Hat Support](https://access.redhat.com/support)

---
Last Updated: November 2024

Note: Release timelines are subject to change.