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

Add ADR for new KDM branching strategy #4766

Open
wants to merge 1 commit 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
31 changes: 31 additions & 0 deletions docs/adrs/006-kdm-strategy.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
# 6. KDM Branching Strategy for RKE2

Date: 2023-09-14

## Status

New

## Context

Rancher Manager uses [KDM](https://github.com/rancher/kontainer-driver-metadata/) for its integration of RKE2. This manages the following behaviors for each RKE2 version:
Copy link
Member

Choose a reason for hiding this comment

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

Should the ADR go here, in KDM, or ecm-distro-tools? This feels like an overarching issue where we want to observe parity for both K3s and RKE2, and the change were discussing doesn't really affect the distro - so I don't feel like it belongs in this repo.

- Minimum Rancher Manager version
- Maximum Rancher Manager version
- Default version when provisioning via Rancher Manager
- Server Args in RKE2 version
- Agent Args in RKE2 version
- Chart versions in RKE2 version
- Specific Rancher Manager features, such as secrets encryption

Changes for RKE2 are made in the `channels-rke2.yaml` file, and then `go generate` is run to update the `data.json` file with these changes. The `data.json` file is the only file Rancher Manager itself uses.

When a change goes into the `release-x.y` branch of KDM, that is considered production and becomes live for all users of Rancher Manager. The current branching strategy waits for the Rancher Manager team to set a specific development branch in KDM to make PRs and merges against so that the RKE2 team can validate its integration with Rancher Manager. The Rancher Manager team also makes changes in that branch of KDM that they want to release by a certain date, often to enable the latest Kubernetes patch versions for RKE1.

## Decision

To enable a "release-when-ready" approach in KDM, we will have specific branches dedicated to RKE2 in KDM. This allows the Rancher Manager team to release either new RKE1 versions or new RKE2 versions at separate times. It also reduces the cross-team impact of KDM releases as each team will only have their own branches to manage.

## Consequences

When releasing KDM, a new `go generate` might have to be run to ensure data is not lost from the `data.json` file, depending on how Github does with merges on this file.