Add leader election to deployment

[msau42]

So that we can catch issues like
kubernetes-csi/external-attacher#144

[msau42]

/help

[k8s-ci-robot]

@msau42:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

Details

In response to this:

/help

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.

[pohly]

Do we need testing with and without leadership election? Probably yes, because those go through different code paths.

Testing with leadership election isn't going to be very realistic in the Prow CI because it creates a cluster with just one node. We'll execute some additional code paths, but not the actual leadership election. My preference would be to switch to a multi-node KinD cluster for all testing. It's the more realistic case.

[pohly]

Maintaining all these different deployments is going to become more complicated. Would it be useful to start generating them with kustomize?

I've done that in PMEM-CSI such that kustomize is only needed when editing the input files. Users and the CI still get complete deployment files. See intel/pmem-csi@6037be5 for details. It wouldn't be hard to move that over to csi-driver-host-path.

[msau42]

Long term I think a multi-node cluster would be great.

Regarding managing deployment, I'm fine with kustomize. I'm also biased because I use it for PD driver too, and it's been working decently well for testing various configs like alpha, stable, staging, dev

[pohly]

@msau42 what about testing with and without leadership election? Do you think we need to test both?

[zhucan]

Why need to add leader election to deployment for csi-driver-host-path? Maybe creating two pod in the same time but in different node

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten