Change Leader Election Config Map for Chains Controller

[khrm]

Currently, the chains controller assumes config-leader-election configmap as the name for the leader election configmap. This is the default name for the Knative controllers' leader election configmap. If some other controllers also exist, it's a good practice to have a separate configmap for every controller.
Fixes #1024

Changes

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs included if any changes are user facing
• Has Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including
  functionality, content, code)
• Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
• Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

BREAKING CHANGE:
The name of the configmap for leader election of chains controller has been changed to
`tekton-chains-config-leader-election` from default `config-leader-election`.
Any existing users of this configmap are requested to override the name to back to `config-leader-election`,
or migrate their existing config to `tekton-chains-config-leader-election`.

[khrm]

/kind bug

[wlynch]

Lgtm, but this should be called out as a potentially breaking change in the release notes, since this will affect anyone relying on the previous behavior.

[vdemeester]

@wlynch given we did not ship the configmap at all in the chains release, do we think a lot of people relied on it ?
Anyway, I agree, we need to highlight that in the release changelog yes.

[wlynch]

@wlynch given we did not ship the configmap at all in the chains release, do we think a lot of people relied on it ? Anyway, I agree, we need to highlight that in the release changelog yes.

Technically the feature has always existed because of our usage of the knative controller framework, but we never really advertised it. This is changing the default configmap that chains looks for, which would technically break anyone currently setting the existing default knative leader election configmap (which I assume is how @khrm discovered this).

I agree its unlikely that many people were aware that this feature existed, which is why I'm fine with making the change even though it's potentially breaking. But we should update the PR description release notes with the change + instructions for how to revert back to the old behavior if needed.

[khrm]

/kind feature
/remove kind bug

[khrm]

@wlynch I have added the Breaking change note. And also updated the PR description.

[khrm]

/kind remove bug

[tekton-robot]

@khrm: The label(s) kind/remove cannot be applied, because the repository doesn't have them.

In response to this:

/kind remove bug

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/test-infra repository.

[khrm]

/remove-kind bug

[vdemeester]

/approve
/cc @wlynch @lcarva

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lcarva, vdemeester

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 [lcarva]

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

[lcarva]

@wlynch, I think your comment was addressed, but before I add the lgtm label, I want to make sure you have a chance to take another look.

[wlynch]

Made some tweaks to the release note, but otherwise lgtm!

/lgtm

Dismissing because Billy has already mentioned LGTM above.