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 <ncopa@alpinelinux.org> 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" <sir@cmpwn.com> 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