kubernetes-sigs / kubernetes-sigs/cluster-api

RuntimeSDK: clusterctl should check if a CAPI upgrade would break extensions

Open
#6,904 7 comments 0 reactions 0 assignees View on GitHub
area/clusterctl area/runtime-sdk help wanted kind/feature priority/important-longterm triage/accepted
Dominant language
Go
Stars
4.3k
Forks
1.6k
Avg merge
1d 3h
Merged PRs (30d)
113

Description

**User Story**

As an operator I would like to get a warning/error when running `clusterctl upgrade apply/plan` when the upgrade would break currently deployed Runtime Extensions.

**Detailed Description**

Background information:

* Runtime Hooks can have multiple apiVersions just like regular API types
* When creating a new apiVersion of a Runtime Hook we can deprecate the old version
* Runtime Extension authors can still use the old version of the Runtime Hook, but they are expected to migrate to the new apiVersion before the old one is removed
* After deprecation the old apiVersion will be eventually removed. At this time a Runtime Extension using the old and now removed apiVersion would stop working

**Anything else you would like to add:**

The rough idea is to add a precheck to clusterctl. clusterctl would check if the new CAPI version has removed a Runtime Hook version which is currently used by a Runtime Extension.

Notes:
* To verify if a used version is dropped we need the following information:
* Which Runtime Hook versions still exist in the current CAPI version. This information can be "hard-coded" into clusterctl via a catalog. But this means the check only works if the `clusterctl` version is the same as the corresponding new CAPI controller version.
* Which Runtime Hook versions are currently used. Today we only have this information in the discovery info in the ExtensionConfig status.
* We can already implement this, but the check only becomes relevant once the first Runtime Hook version has been removed.

/kind feature

Contributor guide

Open the contributing guide

Research direction

Start with the clusterctl upgrade apply/plan entry points and the Runtime Extension discovery information in ExtensionConfig status. Determine how the current and target CAPI Runtime Hook versions would be compared, including the catalog approach, and define the warning or error shown when an upgrade removes a version still in use.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
cli
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.