pluggable leader election strategy

[lionelvillard]

For #3157

Proposed Changes

• Allow for various leader election strategies.

Release Note

Docs

Since the implementation provided by k8s is buggy and not optimal (pull only) we need a way to replace it.

Depends on #3384

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lionelvillard

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [lionelvillard]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[aslom]

/assign

[aslom]

Going though the code - looks like functionality like that is needed for HA scalable adapters in Knative eventing.

I think we should experiment with it and to do this we need that code to be in knative eventing

[aslom]

/lgtm

[matzew]

I see a WARNING: DATA RACE reported in the failed test

[lionelvillard]

I saw that. It's in the k8s go client lib. Instead of copy&paste this code maybe we should just patch it but I don't know how to do this now that we use go mod. Wrong comment for this PR.

[knative-metrics-robot]

The following is the coverage report on the affected files.
Say /test pull-knative-eventing-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/adapter/v2/main.go	63.3%	61.9%	-1.4
pkg/adapter/v2/main_message.go	58.7%	56.4%	-2.3
pkg/leaderelection/context.go	Do not exist	78.8%

[aslom]

I think we need that code and tests passed.

/lgtm

[mattmoor]

I just came across this trying to enable HA by default for our controlplane components, which eliminates the enabledComponents and the LeaderElect fields from knative/pkg.

This code has zero eventing dependencies, and forks a ton of the PKG logic into eventing. 😞

Is there a design or a feature track document for this anywhere...?

[lionelvillard]

this code is almost the same as the one found in PKG except it depends on adapter.Adapter instead of reconciler.LeaderAware. (there was issues with directly imported adapter.Adapter from context.go so the interface is duplicated in this file).

I would like to consolidate the two together, and maybe reconciler.LeaderAware is the right abstraction but I'm not sure yet. That's on my TODO list for 0.17.