clusterctl does not support v1beta1 from 1.11.0 even when deprecation is still runing

[antaloala]

What steps did you take and what happened?

I have been testing several clusterctl releases against a define CAPI Cluster using v1beta1, getting the following printouts (note I have renamed the downloaded clusterctl binaries shown here below with its related version):

$ ./clusterctl-1.13.0 describe cluster multinode-cluster -n default
Error: this version of clusterctl could be used only with "v1beta2" management clusters, "v1beta1" detected

$ ./clusterctl-1.11.0 describe cluster multinode-cluster -n default
Error: this version of clusterctl could be used only with "v1beta2" management clusters, "v1beta1" detected

$ ./clusterctl-1.10.10 describe cluster multinode-cluster -n default
NAME                                                       READY  SEVERITY  REASON     SINCE  MESSAGE
Cluster/multinode-cluster                                  False  Warning   ScalingUp  13m    Scaling up control plane to 3 replicas (actual 1)
├─ClusterInfrastructure - Metal3Cluster/multinode-cluster  True                        13m
└─ControlPlane - RKE2ControlPlane/multinode-cluster        False  Warning   ScalingUp  13m    Scaling up control plane to 3 replicas (actual 1)
  └─Machine/multinode-cluster-nbw6g                        True                        13m

What did you expect to happen?

As the v1beta1 deprecation is still running (it is to be removed in April 2027) I understand newer clusterctl releases >= 1.11.0 should keep supporting it, removing that support once the ongoing deprecation finishes (i.e., once v1beta1 support being finally removed).

Cluster API version

I have tested several clusterctl versions (as shown above):

• the current latest one 1.13.0
• the first one from which v1beta1 is not supported anymore: 1.11.0
• the latest one still supporting v1beta1: 1.10.10

Kubernetes version

$ kubectl version

Client Version: v1.35.4
Kustomize Version: v5.7.1
Server Version: v1.34.4

Anything else you would like to add?

No response

Label(s) to be applied

/kind bug
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

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.

[2003Aditya]

 I ran into the same issue and took a closer look at what's happening.                                                                          
                                                                                                                                                
 When you run `clusterctl` describe (or `get-kubeconfig`, delete, move), it checks what API version                                                 
 your management cluster is using. The problem is that starting from `v1.11.0`, these commands are                                                
 rejecting `v1beta1` clusters even though `v1beta1` is still supposed to be supported until April 2027.                                             
                                                                                                                                                
 The root cause is that certain commands ("upgrade" is the exception) don't explicitly tell the                                                 
 version checker to allow `v1beta1`. The code has a `GetCompatibleVersions()` function that says                                                    
 "v1beta2 clusterctl should work with v1beta1 clusters", but that logic isn't being used when you                                               
 run describe or `get-kubeconfig`.                                                                                                                
                                                                                                                                                
 Looking at the affected files:                                                                        
 - `describe.go`:76 - doesn't allow `v1beta1`                                                                                                       
 - `get_kubeconfig.go`:46 - doesn't allow `v1beta1`                                                      
 - `delete.go`:78 - doesn't allow `v1beta1`                                                                  
 - `move.go`:147 - doesn't allow `v1beta1 `                                                                                                         

 Compare this to `upgrade.go`:62 which does it correctly:                                           
    clusterClient.ProviderInventory().CheckCAPIContract(ctx, cluster.AllowCAPIContract{Contract:                                                   
 "v1beta1"})                                                                                                                                    
                                                                                                                                                
 The fix would be to either:                                                                                                                    
 1. Add AllowCAPIContract{Contract: "v1beta1"} to those commands, or                                   
 2. Make CheckCAPIContract() automatically accept compatible versions from GetCompatibleVersions()                                              
                                                                                                          
 I can work on a PR if this approach makes sense.                                                    

[fabriziopandini]

As per https://cluster-api.sigs.k8s.io/reference/versions.html?highlight=compatibility#cluster-api-release-vs-contract-versions

Compatibility with older contract versions, when implemented, is only intended to ease the transition for providers, and it will be considered in a very limited set of operations e.g. ...

• describe.go:76 - doesn't allow v1beta1
• get_kubeconfig.go:46 - doesn't allow v1beta1
• delete.go:78 - doesn't allow v1beta1
• move.go:147 - doesn't allow v1beta1

Are not included in the list of the operations for which we support compatibility.

While it make seem easy to make the change, extending support implies also expanding the test matrix and the continous effort to keep care of it, and we don't have enough bandwidth to do do.