This message was deleted.

I’m not a maintainer of RKE2 and don’t know all the details about how the project manages certificates. On the quick look the script seems to be replicating behavior which automatically synchronized certificates to the management cluster. CAPRKE2 does not provision any certificates of the bundle after creating the initial machine, so the desired state will be to match the certificates from the filesystem with the management cluster secrets at all times, where the source of truth is always in the child cluster filesystem, managed by RKE2

On the quick look the script seems to be replicating behavior which automatically synchronized certificates to the management cluster.

not sure what you mean? do you mean the equivalent of what https://github.com/rancher/cluster-api-provider-rke2/pull/265 was doing ?

@worried-electrician-89379 We had a chat with @limited-football-68766, we think it might be better to run the script before upgrading to v0.7.1. In v0.27, the secret wont be used anywhere for etcd management so it should be safer to create it on older release, then after update CAPRKE2 is going to start using it. Would you be able to test this flow? also maybe perform a scale up/down of CP machine. If any issues appear, we're happy to assist.

ok, thanks for the feedback I was looking at a CI run earlier today (playing this scenario) and I noticed that the Secrets are created by CABPRKE2 before my tool has a chance to run