Update module sigs.k8s.io/controller-runtime to v0.12.0

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
sigs.k8s.io/controller-runtime	require	minor	v0.11.2 -> v0.12.1

---

Configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, click this checkbox. ⚠ Warning: custom changes will be lost.

---

This PR has been generated by WhiteSource Renovate. View repository job log here.

[thbkrkr]

Breaking change:

• ⚠ leaderelection: use 'leases' as default resource lock object kubernetes-sigs/controller-runtime#1773

See kubernetes/kubernetes#107454 for migration steps.

06360dd puts the operator in version x+1: use configmapsleases for leader election, this client will use both configmaps and lease objects, so that new (x+1) client can work with old (x) clients.

74fcaa5 adds the RBAC permissions for coordination.v1/lease.

[thbkrkr]

@elasticmachine run elasticsearch-ci/docs

[naemono]

Any reason not to use Leases, which are the default now?

diff --git a/cmd/manager/main.go b/cmd/manager/main.go
index d12486242..9ea48643b 100644
--- a/cmd/manager/main.go
+++ b/cmd/manager/main.go
@@ -474,7 +474,7 @@ func startOperator(ctx context.Context) error {
                Scheme:                     clientgoscheme.Scheme,
                CertDir:                    viper.GetString(operator.WebhookCertDirFlag),
                LeaderElection:             viper.GetBool(operator.EnableLeaderElection),
-               LeaderElectionResourceLock: resourcelock.ConfigMapsResourceLock, // TODO: Revert to ConfigMapsLeases when support for 1.13 is dropped
+               LeaderElectionResourceLock: resourcelock.LeasesResourceLock,

Also likely need to test an upgrade to this version to ensure things transition smoothly with the locks...

[thbkrkr]

Any reason not to use Leases, which are the default now?

This is to provide at least one version of the operator with the transitional type of resource lock configmapsleases that offers a smooth migration path. I did some testing with only Lease with 10 replicas for the operator StatefulSet and I could observe two different operator pods in two different versions reconciling Elastic resource in //.

This can be a real problem depending on the version you are upgrading from. Currently, all operator versions only use configmaps. If you upgrade from a relatively old version of the operator, which means that "some things have changed" since then, to the lease version, you may find yourself in a situation where the two operators are fighting to reconcile resources, which can disrupt your Elastic resources if you don't have HA configurations.

This make me think that we may want to retain the intermediate type of lock (configmapsleases) for more than one version of the operator, if we want to maximize the number of users who will do the migration properly, as we cannot be sure that all of our users will upgrade to the next version. We could look at telemetry to help (e.g.: 95% of the users will install one of the next 3 versions.)

[naemono]

makes perfect sense @thbkrkr thanks!