-
Notifications
You must be signed in to change notification settings - Fork 827
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
dl.k8s.io: Redirect CI URIs to Kubernetes Community infra #1857
dl.k8s.io: Redirect CI URIs to Kubernetes Community infra #1857
Conversation
krel ci-build has been successfully building and pushing CI Kubernetes builds for a time now. Updating this redirect (dl.k8s.io/ci) to Kubernetes Community infra moves us closer to no longer relying on the kubernetes-release-dev (Google-owned) bucket. Signed-off-by: Stephen Augustus <[email protected]>
All Kubernetes builds that land in the 'ci' directory of k8s-release-dev are cross builds, so this reference is no longer required. Signed-off-by: Stephen Augustus <[email protected]>
/hold for Aaron's feedback /assign @spiffxp @BenTheElder @LappleApple @puerco @sladyn98 -- This is the PR I was referring to in today's RelEng triage session. |
What's the retention on these buckets currently and are the contents equivalent now? |
also should this wait for 1.21 wrap up ..? |
Ref: #1569 |
$ gsutil retention get gs://k8s-release-dev
gs://k8s-release-dev/ has no Retention Policy.
$ gsutil retention get gs://kubernetes-release-dev
gs://kubernetes-release-dev/ has no Retention Policy. The contents are roughly equivalent for active release branches as the new
Absolutely fine for this to wait until 1.21 is wrapped. |
#525 (comment) re: retention |
Just so we have it in both places:
@spiffxp -- This is awesome! Just curious, is this a general FYI or something you'd consider using here? Mentioning because I think we're only concerned w/ non-container build artifacts for gs://kubernetes-release-dev, right? |
@spiffxp @BenTheElder -- How are we feeling about this now that v1.21.0 has shipped? |
Ah right, brain misfired re: retention. I somehow lumped k8s-staging-ci-images into this. So my concern with switching right now is possible increased support burden, aka handling "why is my CI job failing?" emails/issues/slack-messages. We still have (flake-induced) diffs between
If I knew someone had bandwidth to actively babysit this or handle an increased support burden, I would feel more comfortable flipping the switch to find out. FWIW there are also some community jobs that still need to switch over
|
I think we should do this in 1.21 👍 @neolit123 can you or one of the other kubadm/kinder contributors / users comment on if this looks ready for your usage? Otherwise we primarily have kube-up and kops to consider at the moment, I think. In terms of in-tree projects. They largely look the same and I think this should "just work" ™️ |
Yes, this should be a prerequisite for flipping the switch. I don't think it should be overly challenging to setup a periodic one-way sync? |
i think this should be fine. both kinder and kubeadm use:
maybe we can switch from https://dl.k8s.io to the direct prod bucket eventually (to be more consistent about URLs in these tools). |
Using a regex in these comparisons to exclude some paths:
If I list one level deep, things look flaky but not too bad:
If I list recursively though things look off:
Stuff only in k8s-release-dev is 24 flaky builds that line up with above report
Stuff only in kubernetes-release-dev is:
The 27 files in question:
These files were in both buckets as far back as the retention window goes:
Then, they stopped appearing in k8s-release-dev (only appearing in kubernetes-release-dev) as of these builds:
Is this a change that didn't get ported back to the deprecated builds? |
@kubernetes/release-managers -- Can I ask one of you to help provide feedback on Aaron's investigation? |
Getting current: slightly better (common went from 87.0% to 90.1%), but still not where we need to be
The questions in #1857 (comment) remain unanswered. |
/sig testing |
A fun wrinkle I realized while asking myself "wait, why don't I just use The files in each bucket that have matching filenames are not bit-for-bit identical files, nor do they have matching timestamps, since they're built in two different jobs at two slightly different times. So rsync will by default try to overwrite basically everything. |
I am FWIW willing to flip the switch and find out what happens over what will be for some a long holiday weekend. I realize code freeze is coming up, but the next few days should be quiet, and I can be available to revert if need be. |
In favor of this. |
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.
/approve
/lgtm
Going to flip the switch and see what happens. I will be available to revert if things blow up. Mindful of impacting the run up to code freeze.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: justaugustus, 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 |
/hold cancel |
Opened #2291 with a script I've been using to keep an eye on the delta between gs://k8s-release-dev and gs://kubernetes-release-dev |
@@ -158,7 +158,7 @@ data: | |||
# Don't require /release/ if you want to get at the Kubernetes release artifacts, the common case. | |||
rewrite ^/(v[0-9]+\.[0-9]+\.[0-9]+(-(alpha|beta|rc)\.[0-9]+)?/.*)$ https://storage.googleapis.com/kubernetes-release/release/$1 redirect; | |||
# Provide a convenient redirect for CI (continuous integration) artifacts as well, which live in a different bucket. | |||
rewrite ^/ci(-cross)?/?(.*)$ https://storage.googleapis.com/kubernetes-release-dev/ci$1/$2 redirect; | |||
rewrite ^/ci/?(.*)$ https://storage.googleapis.com/k8s-release-dev/ci$1/$2 redirect; |
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.
Two things I noticed when trying to deploy:
ci-cross
is still referenced here, and cutting .debs may be broken until this code is fixed: https://github.com/kubernetes/release/blob/6e3b30b6dd78b705474a1086f2ed7f7b8364029b/packages/deb/build.go#L291-L302- removing the first capture group
(-cross)
means the the replacement is incorrect
Fixup PR inbound
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.
Ahhh, regex, my old enemy.
Thanks for the cleanup, Aaron.
I'll fixup the k/release references.
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.
Opened #2292
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.
* `ci-cross` is still referenced here, and cutting .debs may be broken until this code is fixed: https://github.com/kubernetes/release/blob/6e3b30b6dd78b705474a1086f2ed7f7b8364029b/packages/deb/build.go#L291-L302
Fixed in kubernetes/release#2153.
I deployed using the contents of #2292
Deployed to prod
I'm going to assume this is eventually consistent, waiting a bit |
Yup, good now
|
OK so as of ~2020-07-03 00:15:00, https://dl.k8s.io/ci redirects to Any breakages, report them here. Broader notification later. |
dl.k8s.io: Redirect CI URIs to Kubernetes Community infra
krel ci-build has been successfully building and pushing CI Kubernetes
builds for a time now.
Updating this redirect (dl.k8s.io/ci) to Kubernetes Community infra
moves us closer to no longer relying on the kubernetes-release-dev
(Google-owned) bucket.
ref: ci-kubernetes-build-canary: Migrate from bootstrap to krel test-infra#20663, Deprecate google-hosted kubernetes-build jobs test-infra#20964
dl.k8s.io: Remove ci-cross redirects
All Kubernetes builds that land in the 'ci' directory of k8s-release-dev
are cross builds, so this reference is no longer required.
ref: version-markers: Remove usage of the ci/k8s-master marker test-infra#18517
Signed-off-by: Stephen Augustus [email protected]
Part of kubernetes/release#1711 and #1569