Update overlays #921
Update overlays #921
Conversation
k8s-ci-robot
added
release-note-none
|
Hi @amacaskill. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
k8s-ci-robot
added
the
size/XL
| patchesStrategicMerge: | ||
| - no-node-driver-registrar-probe.yaml |
There was a problem hiding this comment.
Is this patch still necessary in stable versions 1-21 to 1-23? @saikat-royc @mattcary
There was a problem hiding this comment.
More background in #830 (comment)
The feature was introduced in node-driver-registrar in v2.4.0, if +1.21 is already using this version then it would be great to remove this patch to see it working
amacaskill
force-pushed
the
update-overlays
branch
6 times, most recently
from
6438a41 to
2ca4c37
Compare
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
Please double check the images transformation by running /ok-to-test |
k8s-ci-robot
added
ok-to-test
amacaskill
force-pushed
the
update-overlays
branch
from
2ca4c37 to
6be1936
Compare
Ran
|
amacaskill
force-pushed
the
update-overlays
branch
2 times, most recently
from
df51595 to
da67aec
Compare
| @@ -3,7 +3,7 @@ kind: ImageTagTransformer | |||
| metadata: | |||
| name: imagetag-gcepd-driver-prow-head | |||
| imageTag: | |||
| name: gke.gcr.io/gcp-compute-persistent-disk-csi-driver | |||
| name: k8s.gcr.io/cloud-provider-gcp/gcp-compute-persistent-disk-csi-driver | |||
There was a problem hiding this comment.
so this is a bug fix. the original transformation from gke.gcr.io/gcp-compute-persistent-disk-csi-driver to gcr.io/k8s-staging-cloud-provider-gcp... was not working. since prow-gke-release-staging-head was based on stable-master which uses k8s.gcr.io/cloud-provider-gcp/gcp-compute-persistent-disk-csi-driver.
There was a problem hiding this comment.
Correct. Back in January the pd-master-sidecars-latest-k8s-master-on-gce tests were failing because of this so it has been known this needed to be fixed, but I just thought I would do it in this PR.
| --- | ||
| apiVersion: builtin | ||
| kind: ImageTagTransformer | ||
| metadata: | ||
| name: imagetag-csi-node-registrar-prow-rc | ||
| imageTag: | ||
| name: k8s.gcr.io/sig-storage/csi-node-driver-registrar | ||
| newTag: "v2.3.0" | ||
| newTag: "v2.5.0" | ||
| --- | ||
| apiVersion: builtin | ||
| kind: ImageTagTransformer | ||
| metadata: | ||
| name: imagetag-csi-gce-driver-prow-rc | ||
| imageTag: | ||
| name: k8s.gcr.io/cloud-provider-gcp/gcp-compute-persistent-disk-csi-driver |
There was a problem hiding this comment.
Just to clarify the release candidate validation process:
The prow-gke-release-staging-rc-master overlay was used to validate release candidates (say we cut a v1.5.0-rc1 tag, then we apply transformation:
name: k8s.gcr.io/cloud-provider-gcp/gcp-compute-persistent-disk-csi-driver
newName: gcr.io/k8s-staging-cloud-provider-gcp/gcp-compute-persistent-disk-csi-driver
newTag: "v1.5.0-rc1"
Verify the job succeeds and then we cut 1.5.0.
push the image to prod (i.e it will become available in k8s.gcr.io/cloud-provider-gcp/gcp-compute-persistent-disk-csi-driver:1.5.0), then remove the transformation in prow staging overlay and update stable master to use 1.5.0.
If the intention is use to this overlay to validate release candidates, we should name this overlay prow-release-staging-rc-master (instead of prow-stable-sidecar-master).
Otherwise prow-stable-sidecar-master and stable-master is the same.
So regarding your question whether to keep this transformer for this overlay? Yes we should keep the image transformation file.
Thoughts? @mattcary @amacaskill
There was a problem hiding this comment.
In the meeting we had on overlays, we proposed to rename prow-gke-release-staging-rc-master to prow-stable-sidecar-master. Would prow-stable-sidecar-latest-rc be a better name? Recall, prow-gke-release-staging-rc-master is Do driver build: false, stable sidecar versions, latest release candidate, and k8s master.
A couple questions on the candidate release process:
We proposed to move prow-gke-release-staging-rc-master upstream. This is the upstream manifest that I added for prow-gke-release-staging-rc-master. It doesn't test a release candidate currently because it takes the argument release-1-4, but maybe this is wrong and it should not have the release-1-4:
--repo=sigs.k8s.io/gcp-compute-persistent-disk-csi-driver=release-1-4
Assuming the release-1-4 is incorrect and the argument is:
--repo=sigs.k8s.io/gcp-compute-persistent-disk-csi-driver
When we do want to test a release candidate, say v1.5.0-rc1, when we cut a v1.5.0-rc1 tag, we have to
- Manually add the transformation you described above in this file (deploy/kubernetes/images/prow-stable-sidecar-master/image.yaml) , which applies that newTag: "v1.5.0-rc1".
- We would NOT need to change the upstream test manifest at all like "-repo=sigs.k8s.io/gcp-compute-persistent-disk-csi-driver=release-1-5-0-rc1"
Also am thinking I should replace the upstream test manifest for release 1.3 with release 1.4. We don't need both right?
There was a problem hiding this comment.
stable-master is not supposed to be used to test release candidates. stable-* is the overlay which contains already released candidates.
the job in upstream can be
ci-gcp-compute-persistent-disk-csi-driver-release-k8s-master-integration which takes the main branch's stable-master overlay. Because we always keep the main branch stable-master poiting to the latest released driver version. The purpose of this job is to run the latest stable driver.
another staging job ci-gcp-compute-persistent-disk-csi-driver-release-staging-k8s-master-integration can be added upstream to validate release candidates (e.g 1.5.0-rc1). This job will take the newly created prow-gke-release-staging-rc-master overlay. The purpose of this job is to validate release candidates.
Thoughts?
Also, prow-stable-sidecar-rc-master sounds good to me.
Let's discuss this in a meeting.
There was a problem hiding this comment.
Yes. I have the prow-gke-release-staging-rc-master (which we renamed to prow-stable-sidecar-rc-master) overlay for the latest the latest rc branch upstream, but thanks for clarifying. I will change it to be just the main branch. Instead of release-1-4.
I'll try to summarize all this so we can discuss in a meeting
There was a problem hiding this comment.
yeah let's meet.
I think the overriding goal is to simplify & reduce duplication between internal & upstream
|
did we do a sanity check of stable-1.21, stable-1.22, stable-1.23 overlays by deploying to respective GKE or k8s cluster? |
amacaskill
force-pushed
the
update-overlays
branch
2 times, most recently
from
545fba5 to
e00083c
Compare
|
please update https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver#features-in-development, |
I will make a new PR for this. This one is getting pretty large. |
k8s-ci-robot
added
the
needs-rebase
amacaskill
force-pushed
the
update-overlays
branch
from
e00083c to
de4df0c
Compare
k8s-ci-robot
removed
the
needs-rebase
Yes |
Updated both in PR #932 |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: amacaskill, saikat-royc 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:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
What type of PR is this?
What this PR does / why we need it:
We want to clean up the overlays as we have a lot of overlays that label prow even though they don't correspond to a prow job. This also bumps the sidecars to the latest stable versions. In summary, this PR:
Changes:
Adds:
Removes:
Does this PR introduce a user-facing change?: