This message was deleted.

Sorry for the late reply, As of now, CAPI itself and the providers need to exist on a

Downstream

cluster, not the

Rancher Manager Cluster

(or

local

), and the clusters created by CAPI will need to be imported into Rancher afterwards and will work as any other

imported

RKE2 cluster. There might be an issue if you want to upgrade that cluster from Rancher (using the

system-upgrade-controller

) since CAPI would probably destroy the node and re-create it using the older version. There is no actual roadmap to achieve tight integration yet, this is first of all a community effort for a CAPI-compliant deployment of RKE2. But, there is interest at SUSE to have that so stay tuned!

When you say "There might be an issue if you want to upgrade that cluster from Rancher (using the SUC)...", you are referring to the capi-provisioned cluster imported into Rancher, right? Since Rancher mgmt clusters cannot directly manage other Rancher mgmt clusters, would a valid capbr use case be for capbr clusters to serve as both downstream and upstream clusters that exist between Rancher mgmt clusters? The capbr clusters in this case provide the required isolation between parent/child Rancher mgmt clusters and also provide capi-based automation for managing the full lifecycles of the Rancher mgmt clusters.

About your first note, yes, that's what I meant, capi-provisioned clusters imported into Rancher, will probably need to be upgraded with CAPI, instead of SUC (System upgrade controller) used in Rancher. About your second note, that's an absolutely viable usage, CAPI would make it possible to manage the clusters on which Rancher Manager runs AND would be used to manage lifecycle for downstream clusters. At the moment, where integration with Rancher is not yet done, separating roles of each is the better bet, and it certainly should work in the scenario you are describing.

Thanks for your quick answers to my questions.