Add new per k8s minor version overlays

[saikat-royc]

overlays mappings:
stable-1-15, prow-gke-release-staging-rc-1-15:

• provisioner 1.6.1
• attacher 2.2.1
• driver 1.2.0-gke.0

stable-1-16, prow-gke-release-staging-rc-1-16:

• provisioner 1.6.1
• attacher 2.2.1
• resizer 1.0.1
• driver 1.2.0-gke.0

stable-1-17, prow-gke-release-staging-rc-1-17:

• provisioner 2.1.0
• attacher 3.1.0
• resizer 1.1.0
• snapshotter 3.0.3
• driver 1.2.0-gke.0

stable-1-18, prow-gke-release-staging-rc-1-18:

• provisioner 2.1.0
• attacher 3.1.0
• resizer 1.1.0
• snapshotter 3.0.3
• driver 1.2.0-gke.0

stable-1-19, prow-gke-release-staging-rc-1-19:

• provisioner 2.1.0
• attacher 3.1.0
• resizer 1.1.0
• snapshotter 3.0.3
• driver 1.2.0-gke.0

stable-master, prow-gke-release-staging-rc-master:

• provisioner 2.1.0
• attacher 3.1.0
• resizer 1.1.0
• snapshotter 3.0.3
• driver 1.2.0-gke.0

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:

/kind api-change
/kind bug
/kind cleanup
/kind design
/kind documentation
/kind failing-test
/kind feature
/kind flake

What this PR does / why we need it:
This patch enables mapping driver bundles to k8s minor version

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:
This is first of a multi part patches
Remaining steps:

1. Add test jobs to validate the new overlays (I have tested basic provisioning 1.15 to 1.18 manually, test jobs will run the full test suite)
2. Remove older overlays test jobs
3. Remove older overlays prow-gke-release-staging-rc, stable, update readme.

Note:

1. Snapshotter sidecar has not been updated to 4.x as GKE needs to support v1 crds first.
2. Windows internal prow tests use the alpha overlay which use the base directly hence no overlays changes need to be done. When the windows changes are to be included in stable-* overlays, changes need to be made to prow-gke-release-staging-rc-1-18+, validate tests and then merge in stable-1-18+ overlays.

Does this PR introduce a user-facing change?:

NONE

[saikat-royc]

/assign @verult @mattcary

[saikat-royc]

/hold

[saikat-royc]

/hold cancel

[mattcary]

Jing just submitted #701 which moves windows to stable, do you want to go ahead and make that change now?

[mattcary]

Although the windows images are multi-arch now so maybe it's not necessary.

[saikat-royc]

Jing just submitted #701 which moves windows to stable, do you want to go ahead and make that change now?

Thanks for pointing to this.
Since the changes are non-conflicting. I am thinking of letting #701 merge first, and then add a new patch on top of this new overlays (so that I can test the existing overlays for linux in parallel while windows changes are being reviewed). #704 can be merged in parallel without the windows stuff for now.

[verult]

LGTM on my end. Leader election and metrics stuff looks good.

Might be useful to have the overlay-updating procedures for each scenario (sidecar change, driver change, k8s version addition) in a README, to help prevent unexpected changes. Don't need to block this PR though.

Just to confirm my understanding: for sidecar and driver updates, we first add patches to staging-rc overlays of the k8s versions the change applies to. Once qualified, we revert these patches and add the changes to base (which propagates to stable and staging-rc), and add replace/delete patches to overlays of older k8s versions as necessary.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: saikat-royc, verult

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 [saikat-royc,verult]

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

[saikat-royc]

Might be useful to have the overlay-updating procedures for each scenario (sidecar change, driver change, k8s version addition) in a README, to help prevent unexpected changes. Don't need to block this PR though.

Ack. Will update the readme with new overlay creation steps.

[saikat-royc]

LGTM on my end. Leader election and metrics stuff looks good.

Might be useful to have the overlay-updating procedures for each scenario (sidecar change, driver change, k8s version addition) in a README, to help prevent unexpected changes. Don't need to block this PR though.

Just to confirm my understanding: for sidecar and driver updates, we first add patches to staging-rc overlays of the k8s versions the change applies to. Once qualified, we revert these patches and add the changes to base (which propagates to stable and staging-rc), and add replace/delete patches to overlays of older k8s versions as necessary.

Yes,

for sidecar and driver updates, we first add patches to staging-rc overlays of the k8s versions the change applies to. Once qualified, we revert these patches and add the changes to base (which propagates to stable and staging-rc), and add replace/delete patches to overlays of older k8s versions as necessary.

1. This sounds right. If there is one of change specific to a minor version, that need not propagate to base.
2. If new latest overlay is being created say 1.20, we can create a staging-rc-1-20 overlay (with base as stable-master and whatever diff needed), and test it, and then once tests are green, create a stable-1-20 overlay. Changes which are expected to stay in forseeable future releases can be put in base again (so we dont need to keep creating add patches), and removed from older overlays.

[mauriciopoppe]

/this-is-fine
:D,

My bad, I added a comment in the wrong PR

[k8s-ci-robot]

@mauriciopoppe:

In response to this:

/this-is-fine
:D

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.

[saikat-royc]

/this-is-fine
:D,

My bad, I added a comment in the wrong PR

/this-is-fine

[k8s-ci-robot]

@saikat-royc:

In response to this:

/this-is-fine
:D,

My bad, I added a comment in the wrong PR

/this-is-fine

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.

[mattcary]

/lgtm