-
Notifications
You must be signed in to change notification settings - Fork 159
replace gcr.io/gke-release-staging to use k8s.gcr.io/cloud-provider-gcp #836
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Carlos Panato <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/assign @msau42
for the /approve
newName: gcr.io/gke-release-staging/gcp-compute-persistent-disk-csi-driver | ||
newTag: "v1.2.1-rc1" | ||
newName: k8s.gcr.io/cloud-provider-gcp/gcp-compute-persistent-disk-csi-driver | ||
newTag: "v1.2.2" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on naming scheme I wasn't sure if these needed to correspond to versions listed in kubernetes/kubernetes.
But all I could find were testing manifests that listed a much older version, e.g. https://github.com/kubernetes/kubernetes/blob/release-1.19/test/e2e/testing-manifests/storage-csi/gce-pd/node_ds.yaml#L43
So I'm assuming this is fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These versions match what we're shipping with the managed driver in GKE, so it's probably good to keep them as you've written, ie this is fine.
The manifests in k/k are way out of date. The intent is to test that k/k hasn't broken the CSI interface rather than testing latest versions of PD CSI IIUC.
It's not clear to me that the work on putting the PD CSI driver in cloud-provider-gcp is going to mean we should remove the testing manifests from k/k or not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes as part of that effort we'll remove the manifests from k/k
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cpanato, mattcary, spiffxp 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 |
newName: gcr.io/gke-release-staging/gcp-compute-persistent-disk-csi-driver | ||
newTag: "v1.2.1-rc1" | ||
newName: k8s.gcr.io/cloud-provider-gcp/gcp-compute-persistent-disk-csi-driver | ||
newTag: "v1.2.2" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes as part of that effort we'll remove the manifests from k/k
@@ -4,8 +4,8 @@ metadata: | |||
name: imagetag-gcepd-driver-prow-head | |||
imageTag: | |||
name: gke.gcr.io/gcp-compute-persistent-disk-csi-driver | |||
newName: gcr.io/gke-release-staging/gcp-compute-persistent-disk-csi-driver | |||
newTag: "latest" | |||
newName: gcr.io/k8s-staging-cloud-provider-gcp/gcp-compute-persistent-disk-csi-driver |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also change name
and its source?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would require changing the integration test code which I'd like to do in its own PR so it doesn't get buried---that sort of thing has had knock-on effects with random test pipelines breaking.
Since we are replacing the image in all overlays probably we should take advantage of doing that to change the placeholder name to something that is clearly a placeholder, which might reduce problems in the future.
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Follow up #724
deprecate the
gcr.io/gke-release-staging
and use the images that is promoted to the k8s prod registry or use the images that are built in the staging project/assign @spiffxp @mattcary
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: