use the k8s-staging-images project to build cloud-provider-kind images #33794
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: upodroid 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
area/config
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
@upodroid: Updated the
In response to this:
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-sigs/prow repository. |
| @@ -14,8 +14,8 @@ postsubmits: | |||
| command: | |||
| - /run.sh | |||
| args: | |||
| - --project=k8s-staging-kind | |||
| - --scratch-bucket=gs://k8s-staging-kind-gcb | |||
| - --project=k8s-staging-images | |||
There was a problem hiding this comment.
are we running all cloudbuilds here? we're going to have quota issues fetching the logs etc and we're reducing the isolation of these subprojects??
There was a problem hiding this comment.
(now someone's job that's only supposed to push some other subproject can also push to this staging location, right?)
lots of subprojects are not checking their logs closely when promoting images, if I understand what we're doing correctly: this is risky and we should go back to separate projects per subproject.
cc @kubernetes/sig-k8s-infra-leads
There was a problem hiding this comment.
Are the IAM permissions/ACL defined here not enough to handle this ?
There was a problem hiding this comment.
The plan is for all subprojects to share the single cloudbuild project. The quotas are very high(something like 30 concurrent jobs). k/k will run cloudbuild jobs on its own project given its complexity.
We enforce the expected behaviour by only allowing promoting images from specified sources that we review. In the extremely unlikely situation that a maintainer misconfigures their cloudbuild definition and publishes it against another subprojects registry, the image can't be promoted and is deleted after 90d and they will spot the errors.
Also, humans only have privileges to push to their own respective registries and only prow and infra admins can submit cloudbuild jobs. The only way a cloudbuild job can be submitted by maintainers is via a postsubmit defined in the image pushing folder in the trusted cluster and commits to main branches approved by maintainers.
This approach is much simpler and with a reasonable set of guardrails.
Part of kubernetes-sigs/cloud-provider-kind#155
/cc @aojea @BenTheElder