Migrate away from the kubernetes-release bucket

[puerco]

Context

Release artifact have historically been published to a GCS bucket called kubernetes-release, this bucket is not under community control. As of the week of Aug 19th the release artifacts are being served from a CDN backed by a community bucket.

Currently, the contents of kubernetes-release are mirrored to the community bucket for serving every two hours.

/cc @kubernetes/release-engineering

TODO

Identify processes that need to be moved

We need to comprehensively search our processes to find those relying on data from kubernetes-release. Once we have an idea of which ones are reading and/or writing to the google owned bucket, let's expand the lists below with those that need to be migrated.

Migrating to the community bucket involves two groups of tasks, let's expand these as we find them:

Kubernetes Release Process

• TBD

Internal Processes and Tests

• Get rid of kubernetes-release/archive #3716
• Revisit the release notes index. #3720

[ameukam]

We had many conversations about this in kubernetes/k8s.io#2396.

[BenTheElder]

We should also confirm the GCB project being used.

We need to comprehensively search our processes to find those relying on data from kubernetes-release. Once we have an idea of which ones are reading and/or writing to the google owned bucket, let's expand the lists below with those that need to be migrated.

I believe expected writes are only krel? There's a constant in krel for the bucket.

For reads, we've already made a big push to point things at dl.k8s.io instead, if any more crop up we can fix them later as worst case they won't have new releases until they switch, and the new bucket is intentionally not public read (only through the CDN).

I think it should be:

• make sure krel GCB service account has write to the new bucket (should be done already but double check)
• swap krel to write to the new bucket
• spin down sync job
• confirm next release goes smoothly
• googler (me): drop remaining write permissions to legacy google-containers project

[ameukam]

make sure krel GCB service account has write to the new bucket (should be done already but double check)

It's not done yet. krel leverage the GCB service agent of the kubernetes-release-test GCP project to cut releases.

[BenTheElder]

We should also migrate out of kubernetes-release-test which is in google.com to a project in kubernetes.io, but we could do that in two phases.

[ameukam]

We should also migrate out of kubernetes-release-test which is in google.com to a project in kubernetes.io, but we could do that in two phases.

See: #3425

[ameukam]

/kind feature
/priority important-soon

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[mengjiao-liu]

/remove-lifecycle stale

[BenTheElder]

I think this is all but done, the bucket isn't being written to anymore but I should drop permissions to it on the Google side and we still? need to move the krel jobs out of the internal project into a community project. Not sure if we had a separate tracking issue for the latter.