kubernetes-sigs/cluster-api

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

Open

#6,904 opened on Jul 12, 2022

View on GitHub
 (7 comments) (0 reactions) (0 assignees)Go (1,532 forks)auto 404
area/clusterctlarea/runtime-sdkhelp wantedkind/featurepriority/important-longtermtriage/accepted

Repository metrics

Stars
 (4,267 stars)
PR merge metrics
 (PR metrics pending)

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