-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Kubernetes CI Policy: release-blocking jobs must run in dedicated cluster #18549
Comments
NodePool is probably fine, though it has the downside that you have to explicitly set a matching node selector and taint toleration in every prowjob podspec if you want to actually make it dedicated. there's no abstraction for this, and they're a little verbose. we've done this before when experimenting with ubuntu nodes for kind IPv6 before we'd standardized on that. |
/sig testing |
Current status (not counting issues that are held open to monitor jobs)
Will need to decide how we'd like to define exceptions for the build jobs, and/or dedicate resources to them. |
Duplicate of ci-ingress-gce-e2e that validates the job can run on k8s-infra-prow-build. Ref: kubernetes/k8s.io#1093 Part of : kubernetes#18549 Signed-off-by: Arnaud Meukam <ameukam@gmail.com>
Duplicate of ci-ingress-gce-e2e that validates the job can run on k8s-infra-prow-build. Ref: kubernetes/k8s.io#1093 Part of : kubernetes#18549 Signed-off-by: Arnaud Meukam <ameukam@gmail.com>
Duplicate of ci-ingress-gce-e2e that validates the job can run on k8s-infra-prow-build. Ref: kubernetes/k8s.io#1093 Part of : kubernetes#18549 Signed-off-by: Arnaud Meukam <ameukam@gmail.com>
Duplicate of ci-ingress-gce-e2e that validates the job can run on k8s-infra-prow-build. Ref: kubernetes/k8s.io#1093 Part of : kubernetes#18549 Signed-off-by: Arnaud Meukam <ameukam@gmail.com>
Assigning Dan to TL completion of this. |
Updated description to enumerate all release-blocking jobs and the umbrella issues tracking their progress or the PRs that migrated them |
Ref : kubernetes#19483 Part of: kubernetes#18549 Signed-off-by: Arnaud Meukam <ameukam@gmail.com>
Ref : kubernetes#19483 Part of: kubernetes#18549 Signed-off-by: Arnaud Meukam <ameukam@gmail.com>
Ref : kubernetes#19483 Part of: kubernetes#18549 Signed-off-by: Arnaud Meukam <ameukam@gmail.com>
Ref : kubernetes#19483 Part of: kubernetes#18549 Signed-off-by: Arnaud Meukam <ameukam@gmail.com>
Current status...
We have "canary" versions of these jobs that run on k8s-infra-prow-build, and write to However, there is much out there that depends on the existing jobs that write to I think full completion of the deprecation process is out of scope for this issue. So I would like us to identify what the minimum set of jobs/scripts/etc should be pulling from |
/milestone v1.21 |
/priority important-soon |
I think the following PRs can close this out:
|
/assign |
Tangentially related: followup work to deprecate google-hosted artifacts related to release-blocking builds will be tracked under kubernetes/k8s.io#1571 |
/close |
@spiffxp: Closing this issue. 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/test-infra repository. |
Part of #18551
Why it's necessary:
What decisions do we need to make:
Boskos projects to be added:
Jobs to be migrated
periodic-kubernetes-bazel-build-master(was moved to release-infoming)TODO:
The text was updated successfully, but these errors were encountered: