-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Update documentation to reflect the use of community-owned package repository pkgs.k8s.io #42810
Comments
@reylejano: GuidelinesPlease ensure that the issue body includes answers to the following questions:
For more details on the requirements of such an issue, please see here and ensure that they are met. If this request no longer meets these requirements, the label can be removed 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. |
@reylejano One tricky thing here is that we won't have packages for all versions back that far. Some of the patch releases will but not others. |
/triage accepted We're on a tight schedule |
Is there an issue - in some other repo - about filling in gaps there? |
I'll be helping with this. |
How's the work going?
|
@sftim I'll come up with something this week :) |
Please, please, consider rolling back these changes until the page makes it clear:
At a minimum, please restore the info about the Google repos for now. Please consider documenting how to install a version different from v1.28: people do need to do that, and it needs to be documented. This is a bit of a screw up. |
The whole community is moving forward constantly, in a fast pace. We the docs team has been updating the main branch to follow whatever changed in the upstream repo/projects. |
Regarding the change of package repository, please report your concern to the sig-release group. We are documenting the facts for users but we don't manage that change. |
No, you are the correct address. Don't push this on the sig-release group; what they did makes sense. It's the doc page that is not serving the community. People have been coming to this page for many releases to learn how to install kubeadm. It has not been necessary to go back to archived versions of the K8s docs to install to a previous version. Which is confusing the hell out of users. I get 7 to 10 support request from users in our course due the change in the docs that happened in August. You just made it worse. Don't send me to the release team. They are not responsible for doing this. You folks are. In particular, this page needs to make clear how to install to any supported Kubernetes version, so please consider parameterizing the "1.28" strings in URLs. People who need to install v1.26 or v1.27 (supported versions!!!) are not told that your procedure WILL NOT WORK FOR THEM. And for versions previous to v1.27, they will not find releases at all. This is easily prevented: DOCUMENT THE GOOGLE REPOS AND NOTE THAT THEY WILL BE NEEDED FOR SOME INSTALLS. No one on the release team is forcing you to do what you are doing here. This is your responsibility. Own up to it. |
At a minimum, please roll back the change to the page that was made on 9 October (approx). The community is transitioning to the new repos. You are going to need to document use cases where the new repos cannot be used. |
Okay, let's take a step back, focus on the problems to resolve.
Yes. The new instructions only works for the new versions. Version before 1.24 becomes a history and we have a convention to stop maintaining V-4 or older releases. Even for V-4 -> V-1, we only fix critical bugs.
The thing is not about whether the instructions are removed. It is that those repos will be removed at any time. We have to move on. It is not that we don't want to document that. It is that the infrastructure has been undergoing drastic (disruptive to someone) changes. We don't own the repos, and that is the reason I was suggesting you to go to sig-release.
As I have mentioned, the Google repos are going away. They may get sunset any time soon. |
That is indeed a problem. Take the example of someone who needs to install a v1.27 version. You'd think that it would occur to them to change the URL to change "1.28" to "1.27", but I find that by in large. people assume they can install the version they need using the current docs. So yeah, it needs to be more clear that the new system is version specific, and if you want to install an older version, you need to change the URL. This covers about half of the problem people have installing kubeadm in our labs.
I don't know the "politics" involved in Google's sunsetting of the repos, but if Google does this, I would hope that there is retroactive support via pkgs.k8s.io by sig-releases for any K8s release that is still supported. Are there? If there are, the current doc should probably mention the releases supported by the pkgs.k8s.io repos, in particular, the pattern of the URI that can be used. This won't be in the archived doc versions, since they're not getting updates I'd assume. If there isn't pkgs.k8s.io support for v1.25 and v1.26, I would hope that the Google repos stays up until they are out of their support window. But especially if there isn't support for them, the current doc needs to reference the Google repos, up until they are sunsetted, since that will affect more than students: it will make it difficult for a lot of shops using K8s to update their clusters :-(
They may well, but the docs should cover these repos up until they do. Since it's easy enough to keep a PR warm, it's not that the docs team needs to be caught flat-footed when it happens. But given the potential for disrupting production users of K8s, better to defer removing these references until that happens. |
The install kubeadm document very clearly states the following:
We have never provided backwards-compatibility promises for our documentation. You're supposed to use the same documentation version as your intended Kubernetes version. For example, if you want to install Kubernetes 1.27, you should use docs for 1.27.
The legacy (Google-hosted) repositories are deprecated and frozen. This means that we don't publish any new releases to the legacy repositories. Kubernetes releases that are created after September 13, 2023, are only available in the new community-owned repositories. That said, you should also use the community-owned repositories even for version older than 1.28. We're currently working on updating instructions for earlier docs versions to highlight this.
SIG Release is owning this work (and the relevant KEP), so SIG Release is definitely the correct address. We're trying our best to understand all the feedback that we receive and we very appreciate it, but we also kindly ask all our community members to understand this situation.
As I said earlier, it's clearly stated that these instructions are only for Kubernetes 1.28, but we'll make this message better highlighted.
Yes, there's retroactive support for previous release starting with 1.24.0. Please see the official announcements for more details:
I have to disagree with this point. Providing instructions based on the legacy (Google-hosted) repositories is setting up users for failure. Let's put aside that the legacy repositories might go away at any time. Given that no new releases are published to the legacy repositories, this can make users vulnerable to any vulnerability that might come up in the future. This is very serious and we want users to migrate to the community-owned repositories as soon as possible. It doesn't make sense to document something that's half-functional, or in this case deprecated and frozen. For the end, I would like to repeat what @cpanato said in the other issue: please be more kind and respectful to the community members, a lot of folks are working on this in their free time. We understand that this is a breaking change, but we had to make it and we tried our best to explain reasons for that in the announcement. |
It does state this, however we could add the same advice right at the top of the page, and maybe even link to the available alternative versions (see https://kubernetes.io/docs/home/supported-doc-versions/ for some example templating code). Helping people find the right guide pays off in terms of cutting down the number of issues opened. |
Also this. Folks, if you're looking to add your thoughts to this tracking issue: don't. This is a tracking issue; we're using it to track work. Even if you're upset, that kind of feedback belongs elsewhere. Take notice. |
@sftim I agree with this, I'll see later today how we can improve and better highlight this message |
I created #43458 to clarify that we have a dedicated package repository for each Kubernetes minor version and that the new package repositories are supporting Kubernetes minor releases starting with v1.24.0. |
Others have chimed in with similar responses.
This is incorrect. The main page does not need to include installation for previous versions before v1.28 as the main page is for v1.28. For previous versions, please use the relative page for the specific version. SIG Docs currently maintains pages for v1.24 to v1.28
Installation instructions for v1.24-v1.27 are in their respective pages |
Required docs changes are backported to all supported release branches (v1.27-v1.24) and the provided feedback has been addressed. There are some follow ups required and we have #43666 to track that. I'm going to close this issue. |
@xmudrii: 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. |
The Kubernetes project began publishing to community-owned package repository pkgs.k8s.io and no longer publishes to apt.kubernetes.io and yum.kubernetes.io which are Google-hosted package repositories.
apt.kubernetes.io and yum.kubernetes.io will be frozen on Sept 13, 2023.
See pkgs.k8s.io: Introducing Kubernetes Community-Owned Package Repositories blog post for more details
Documentation for releases starting with 1.24 that points to apt.kubernetes.io or yum.kuberenetes.io need to be updated to point to pkgs.k8s.io
Branches to update:
/help
The text was updated successfully, but these errors were encountered: