Add new warning for kubernetes deb/RPM packages migration #44109
Conversation
k8s-ci-robot
added
do-not-merge/work-in-progress
|
/check-cla |
BenTheElder
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
/hold |
|
lgtm with steering hat on, should push to get this out there asap with so little time before the turndown |
k8s-ci-robot
added
cncf-cla: yes
k8s-ci-robot
added
language/en
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
BenTheElder
force-pushed
the
packages-update
branch
from
51ddc17 to
b01ad55
Compare
|
Seems like a build timeout - |
|
/committee steering |
k8s-ci-robot
added
the
committee/steering
content/en/blog/_posts/2023-08-31-legacy-package-repository-deprecation/index.md
Outdated
Show resolved
Hide resolved
| The legacy Linux package repositories (`apt.kubernetes.io` and `yum.kubernetes.io` AKA `packages.cloud.google.com`)<br/> | ||
| have been frozen starting from September 13, 2023 **and are going away in January 2024**, users *must* migrate.<br/> | ||
| Please read our [announcement](/blog/2023/08/31/legacy-package-repository-deprecation/) for more details. |
There was a problem hiding this comment.
If we need this, can we schedule (and announce) some brownouts, where we briefly change the DNS domains to point to a simple thing returning a 5xx response?
I'd prefer to have a whole new blog article about the shutdown if needed and if feasible.
There was a problem hiding this comment.
The *.kubernetes.io could have brownouts but there's not a lot of time left to implement this and we already urged users to switch.
The project took too long to move off of legacy rapture.
don't really have the bandwidth for a whole new post and this has all the info and already told users they should switch.
There was a problem hiding this comment.
We also don't need the announcement if the project pivots to a static mirror but that work still isn't complete and we're cutting it terribly close at this point on warning people with a real deadline.
There was a problem hiding this comment.
I'll try to see what appetite the K8s infra SIG have for a smoother transition. I think lots of people like the idea, and only a few people would be willing to offer time to help.
There was a problem hiding this comment.
I'm concerned about the timeframe, leads from release and infra + anyone they/we looped in have known about the looming shutdown for O(months) and the need to migrate off for O(years), we only have ~1 month left to warn users in the case that a replacement is not working by then ...
BenTheElder
force-pushed
the
packages-update
branch
from
b01ad55 to
d27b8b7
Compare
BenTheElder
force-pushed
the
packages-update
branch
from
d27b8b7 to
68047be
Compare
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
LGTM label has been added. Git tree hash: 61babf231690999112e916dacd710593a96a7cb5
|
|
👍 from me. |
|
/approve |
|
/approve For steering. |
|
hi @BenTheElder and @pohly – the Kubernetes website has a different list of approvers, which you can always tag when needed by using @kubernetes/sig-docs-en-owners. /approve for docs |
k8s-ci-robot
added
the
approved
Right, sorry, I asked steering members to approve the banner specifically, we need to approve that part and our own approval process involves a majority vote. I wanted to make sure that was clear, but it's not intended to cover the blog post or the rest of this repo. |
|
/approve Yes please! |
|
/hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: BenTheElder, dims, justaugustus, natalisucks, pacoxu, pohly, soltysh 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 |
Previously we only had a vague warning that users should migrate as soon as possible. We now have a more concrete (though technically approximate) timeline that they must migrate before January 2024 and should re-emphasize this change.
Technically the project could redirect these old apt.kubernetes.io and yum.kubernetes.io endpoints to a static snapshot but that will take time, effort, and resources and it's not clear as a project that we should continue to do this versus moving forward with the new community managed host, so in the meantime we should warn that the endpoints as-is will stop working.