Hi! I will start work on setting up the builders for 3.17 release this week. This means that significant changes to the toolchain and bootstrap packages (eg make, binutils, gcc, bison, autoconf, automake, cmake etc) needs to happen within a few days or they will have to be postponed to after 3.17 release. We can also expect a more general feature freeze in aports/main from next week (17 October) and a feature freeze in aports/community wekk after that (24 October). Those are approximate dates and as usual, we do exceptions on case by case basis after that. The 3.17 release is planned for in early November, but depends a but on what shows up during the 3.17 build. Thanks!
Hey Nate, Natanael Copa <email@example.com> writes: > Hi! > > I will start work on setting up the builders for 3.17 release this > week. This means that significant changes to the toolchain and > bootstrap packages (eg make, binutils, gcc, bison, autoconf, automake, > cmake etc) needs to happen within a few days or they will have to be > postponed to after 3.17 release. one question from my side: is there any chance that we move the kubernetes related components (crio, kubeadm, kubectl) from testing to community so that we can versionise k8s releases to make upgrades a bit more easy? Potentially before the 3.17 release so that we can begin with "proper k8s" support? Background: - At the moment kubeadm, kubectl and friends are only in testing - For upgrading a kubeadm created cluster, you need to have kubeadm version-1 (k8s 1.24.x upgraded by 1.25.y, 1.23.a upgraded by 1.24.b and so on) - With upgrading via testing, it is possible to jump 1.22 to 1.25, which then makes it impossible to upgrade the cluster without getting a statically compiled kubeadm from somewhere else Proposed solution: - Within one Alpine version keep one specific Kubernetes minor version (i.e. k8s 1.25.x for Alpine 3.17, k8s 1.26.x for Alpine 3.18, etc.) History/Stability: - At ungleich we have been running k8s cluster for a bit more than 1.5 years based on Alpine now and besides "jumpy upgrades", there are no significant issues - In regards to schedule and version, a short review whether the proposal is feasible: 2021-04-08 k8s 1.21.0 released 2021-08-19 k8s 1.22.1 released 2021-12-16 k8s 1.23.1 released 2022-05-24 k8s 1.24.1 released 2022-09-14 k8s 1.25.1 released 2022-12-06 k8s 1.26.0 will be released 2021-06-15 Alpine 3.14 released 2021-11-24 Alpine 3.15 released 2022-05-23 Alpine 3.16 released 2022-10-xx Alpine 3.17 released Basically, k8s is being released 3x per year, Alpine 2x per year. We can change the k8s version within one minor version without problem, that upgrade is guaranteed to work. However, if we do that, switching from 3.xx to 3.xx+1, we might actually jump two versions, which will make the upgrade via kubeadm fail. However, we can solve this by adding one extra condition: - Every Alpine Linux release would contain 2 k8s releases and as a user I must first upgrade to the latest kubeadm version before upgrade to a new Alpine Linux minor version. How would that look? Given we had phased in k8s before, it would be like this: Alpine 3.14 Originally 1.21.x, upgrades to 1.22.x Alpine 3.15 Originally 1.22.x, upgrades to 1.23.x Alpine 3.16 Originally 1.23.x, uprades to 1.24.x Alpine 3.17: users need to upgrade to latest 3.16 first! Originally 1.25.x, uprades to 1.26.x Alpine 3.18: Originally 1.26.x, uprades to 1.27.x ... If it is too late for 3.17, no worries, but I wanted to kick off that discussion, as currently running k8s on top of Alpine requires one to carefully watch when new kubeadm releases come in. Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch
Also would like to see the big Ceph changes land in community: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33752
"Drew DeVault" <firstname.lastname@example.org> writes: > Also would like to see the big Ceph changes land in community: > > https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33752 Drew, you made my smile a lot. Ceph on Alpine? Seriously? Wow, I am impressed! (*) That is one thing we failed at some years ago, because the packages were practically unusable and is actually the reason why we switched to ceph/rook about 1 year ago from Devuan/Ceph Native. That's a huge step forward, looking forward to seeing ceph natively in Alpine. It could potentially even mean that rook *inside* the container could switch to Alpine based, too. Cheers, Nico (*) No sarcasm, in case that gets lost in the mail. -- Sustainable and modern Infrastructures by ungleich.ch