5 ms·

From my perspective as a former developer on a kubernetes distribution that no longer exists. The model seems to largely be, the CNCF/Kubernetes authors have d

From my perspective as a former developer on a kubernetes distribution that no longer exists. The model seems to largely be, the CNCF/Kubernetes authors have done a good job of writing clear expectations for the lifetime for their releases. But there are customers who for various reasons want extended support windows. This doesn't prevent the distribution from offering or selling extended support windows, so the customers of those distributions can put the pressure on those distribution authors. This is something we offered as a reason to use our distribution, that we can backport security fixes or other significant fixes to older versions of kubernetes. This was especially prevalent for the customers we focussed on, which were lots of clusters installed in places without remote access. This created a lot of work for us though, as whenever a big security announcement came out, I'd need to triage on whether we needed a backport. Even our extended support windows were in tension with customers, who wanted even longer windows, or would open support cases on releases out of support for more than a year. So I think the question really should be, should LTS be left to the distributions, many of which will select not to offer longer releases than upstream, but allow for some more commercial or narrow offerings where it's important enough to a customer to pay for it. Or whether it should be the responsibility of the Kubernetes authors and in that case what do you give up in project velocity with more work to do on offering and supporting LTS. I personally resonate with the argument that this can be left with the distributors, and if it's important enough customers to seek out, they can pay for it through their selected distribution, or switching distributions. But many customers lose out, because they're selecting distributions that don't offer this service, because it is time consuming and difficult to do.

edude03 3y ago
Maybe more importantly, you could get a distribution to support you but what about upstream projects? It'd be a big lift (if not impossible) to get projects like cert-manager cilium whatever to adopt the longer release cycle as well. Is it normal for a distribution to also package upstream projects that customers want?
- kevin_nisbet 3y ago
  > It'd be a big lift (if not impossible) to get projects like cert-manager cilium whatever to adopt the longer release cycle as well. It's a great point which probably should be part of the discussion. Say even if Kubernetes project offered LTS, how would that play into every other project that is pulled together. > Is it normal for a distribution to also package upstream projects that customers want? I suspect it differs by distribution. The distribution I worked on included a bunch of other projects, but it was also pretty niche.
- baby_souffle 3y ago
  > Maybe more importantly, you could get a distribution to support you but what about upstream projects? It'd be a big lift (if not impossible) to get projects like cert-manager cilium whatever to adopt the longer release cycle as well. Exactly this. I see a lot of parallels between k8s releases and OS releases. Even if you're paying microsoft for patches to windows XP, I'm not seeing any of that and the python runtime that most of my software relies on also isn't seeing their cut so... I guess upgrade to at least python 3.10 and then call me back? I would prefer to see the conversation turn more to "what can be done to reduce reluctance to upgrading? How can we make k8s upgrades painless so there's minimal incentive to stick with a long out of date release?"
sgift 3y ago
> But many customers lose out, because they're selecting distributions that don't offer this service, because it is time consuming and difficult to do. Sure, but if they really need that service they will gravitate to distributions that do provide it, so, I think, no harm done here. It's to me like JDK distributions. Some give you six month, some give free LTS and others give you LTS with a support contract. LTS with backports is work, someone has to pay for it, so let those who really need it pay. Everyone else can enjoy the new features. tl;dr: I'm with you in the camp that you can leave it to the distributors.
JohnFen 3y ago
As an industry, we need to get back to having security releases separate from other sorts of releases. There are tons of people who don't want to, or can't, take every feature release that comes down the pike (particularly since feature updates happen so insanely often these days), and this would be a huge win for them.
xnyanta 3y ago
This was my immediate though while reading thr article. Why should the kubernetes authors be burdened by having to maintain an LTS release. That should be Red Hat's job, just like they do with RHEL.

edude03 3y ago

Maybe more importantly, you could get a distribution to support you but what about upstream projects? It'd be a big lift (if not impossible) to get projects like cert-manager cilium whatever to adopt the longer release cycle as well. Is it normal for a distribution to also package upstream projects that customers want?

kevin_nisbet 3y ago
> It'd be a big lift (if not impossible) to get projects like cert-manager cilium whatever to adopt the longer release cycle as well. It's a great point which probably should be part of the discussion. Say even if Kubernetes project offered LTS, how would that play into every other project that is pulled together. > Is it normal for a distribution to also package upstream projects that customers want? I suspect it differs by distribution. The distribution I worked on included a bunch of other projects, but it was also pretty niche.
baby_souffle 3y ago
> Maybe more importantly, you could get a distribution to support you but what about upstream projects? It'd be a big lift (if not impossible) to get projects like cert-manager cilium whatever to adopt the longer release cycle as well. Exactly this. I see a lot of parallels between k8s releases and OS releases. Even if you're paying microsoft for patches to windows XP, I'm not seeing any of that and the python runtime that most of my software relies on also isn't seeing their cut so... I guess upgrade to at least python 3.10 and then call me back? I would prefer to see the conversation turn more to "what can be done to reduce reluctance to upgrading? How can we make k8s upgrades painless so there's minimal incentive to stick with a long out of date release?"

sgift 3y ago

> But many customers lose out, because they're selecting distributions that don't offer this service, because it is time consuming and difficult to do. Sure, but if they really need that service they will gravitate to distributions that do provide it, so, I think, no harm done here. It's to me like JDK distributions. Some give you six month, some give free LTS and others give you LTS with a support contract. LTS with backports is work, someone has to pay for it, so let those who really need it pay. Everyone else can enjoy the new features. tl;dr: I'm with you in the camp that you can leave it to the distributors.

JohnFen 3y ago

As an industry, we need to get back to having security releases separate from other sorts of releases. There are tons of people who don't want to, or can't, take every feature release that comes down the pike (particularly since feature updates happen so insanely often these days), and this would be a huge win for them.

xnyanta 3y ago

This was my immediate though while reading thr article. Why should the kubernetes authors be burdened by having to maintain an LTS release. That should be Red Hat's job, just like they do with RHEL.