Nothing Special   »   [go: up one dir, main page]

Skip to content
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

Add long term stable release branches #7454

Merged
merged 1 commit into from
Oct 18, 2022

Conversation

dmcgowan
Copy link
Member
@dmcgowan dmcgowan commented Sep 29, 2022
  • Adds definition of LTS releases
  • Marks 1.6 as an LTS release

The main motivation behind this addition is to support innovative work going on in containerd while continuing to maintain the most stable version of the software today. The 1.7 release will include new interfaces and implementations of core components of containerd, and while some of these may not be enabled by default in the 1.7 release, they are planned to be either enabled by default or the only options for the following 2.0 release. We expect these implementations to quickly be just as stable and reliable as what exists today, but we recognize the risk of any significant software change to core components. As a project, we must adapt and innovate along with the wider ecosystem, while continuing to be that boring stable component that everyone relies on.

@k8s-ci-robot
Copy link

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

RELEASES.md Outdated Show resolved Hide resolved
RELEASES.md Outdated Show resolved Hide resolved
@dmcgowan dmcgowan marked this pull request as ready for review September 30, 2022 01:33
Copy link
Member
@mikebrow mikebrow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see comments..

RELEASES.md Outdated Show resolved Hide resolved
RELEASES.md Outdated Show resolved Hide resolved
@dmcgowan
Copy link
Member Author
dmcgowan commented Oct 1, 2022

Removed the 1.5 updates, still ongoing discussion of how we want to extend the timeline

RELEASES.md Outdated Show resolved Hide resolved
Copy link
Member
@estesp estesp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member
@mikebrow mikebrow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Signed-off-by: Derek McGowan <derek@mcg.dev>
Copy link
Member
@mikebrow mikebrow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

RELEASES.md Show resolved Hide resolved
patches than non-_LTS_ releases to support the longer term maintainability of the
branch, including library dependency, toolchain (including Go) and other version updates
which are needed to ensure each release is built with fully supported dependencies and
remains usable by containerd clients. There should be at least a 6 month overlap between
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remains usable by containerd clients

this may create an interesting challenge with k8s versions that are out of OSS support. When backporting changes for the active k8s versions, old k8s versions compatibility with containerd may degrade. I'd suggest to phrase something like:

Suggested change
remains usable by containerd clients. There should be at least a 6 month overlap between
remains usable by supported containerd clients. Note, LTS version of containerd may stop working for the containerd clients which are not up to date - you need to seek support from these clients authors. There should be at least a 6 month overlap between

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also in the table in the next section "Kubernetes Support", the list of recommended k8s versions for 1.6 will be fluid now. Bu 2025 recommendation will be different. I think this needs to be specified

Copy link
Member
@mikebrow mikebrow Oct 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

old k8s versions compatibility with containerd may degrade

Not our intention.

k8s versions, and container runtimes, out of OSS support are already a cloud provider issue... non-cve bugs / issues that will not be back ported to n-3 for k8s, and same for container runtimes at EOL, for example.

Wrt. CRI, this change will allow us to back port certain selected non-breaking type changes and extend the span of versions of k8s we can support where the api changes for CRI do not include breaking changes. As an aside breaking changes should require a CRI version change and thus won't, as a practice, be back ported to a prior api version, we currently support 2 versions of CRI and I don't remember off hand if any changes have been breaking. If a breaking change does occur to a version of the api and we have a need to back port it we can work together to figure out a way to disable the breaking behavior for older versions of k8s.. e.g. config switch, identify kubelet version/pod spec as a switch, or some other suitable mechanism.

Obvious statement of the day: Optional apis that are not called by an older version of k8s and optional fields not used by an older version of k8s won't break an older version of k8s.

As you mentioned, we keep a table for k8s support, and if necessary we can expand that table to have a level of detail for optional k8s cri features showing where said cri feature gates/apis may be configured in kubelet and/or containerd..

IOW do the right thing, exercise discretion and care, but have some flexibility. Practice is showing many cloud providers and other container runtime clients, are moving much slower than k8s's quarterly cycle.

the text in RELEASES.md is being left somewhat broad to leave discretion to the maintainers..

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My main point is that in the table of suggested k8s versions there should be a note saying that the list will change over time as we cannot suggest that older (out of support) k8s versions is something containerd recommends to use with containerd 1.6

Copy link
Member
@mikebrow mikebrow Oct 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree in principle from a k/k project support view and not sure we are 100% in sync just yet wrt. containerd recommendation statements in view of this new LTS idea :-) I'll make sure to flag the right k8s people, including you, when we update the containerd k8s support table as we are, of course, integration partners on that statement. We'll definitely want to be clear about what's been tested, what hasn't been tested, the EOL status wrt the k8s versions that are officially EOL/out of support, and possibly where to go for out of support release help, at least in a conceptual way...

k8s versions which are officially out of support by k8s may still be in use, and supported by cloud/platform providers... containerd should continue to run some tests for each branch pr/release even against out of support versions of k8s / CRI, even if just to verify a prior version of the CRI api dropped in a newer version of k8s but not yet removed in the containerd branch.

Having a long term release that goes on as much as 2.5years beyond kubernetes support will definitely expose the support gap more than today's six months to year or so gap between the length of time an old version of containerd is supported and k8s support by the n-3 rule. Gap example in the below table.. we support 1.5.11 with k8s 1.20 even though that version of k8s is out of support.

Cheers.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Y'all can figure out the clearest way to convey K8s support in a follow up or when we add the next K8s release into the list.

@SergeyKanzhelev
Copy link
Contributor

Great! I left couple suggestions on clarifying how LTS will be compatible or not compatible with k8s versions.

@dmcgowan dmcgowan merged commit 8d6350f into containerd:main Oct 18, 2022
@dmcgowan dmcgowan deleted the add-lts-release branch April 20, 2024 00:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.