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.

Sign up for GitHub

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

005: Add proposal for SpinKube releases #14

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

005: Add proposal for SpinKube releases #14

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions proposals/005-skip-template/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
# SKIP 005 - SpinKube Releases

Summary: A proposal to create SpinKube releases which denote a stable set of releases of the SpinKube projects.

Owner: [email protected]

Impacted Projects:

- [x] spin-operator
- [x] `spin kube` plugin
- [x] runtime-class-manager
- [x] containerd-shim-spin
- [ ] Governance
- [ ] Creates a new project

Created: 10-31-2024

Updated: 10-31-2024

## Background

SpinKube is a collection of four projects, the container-shim-spin, Spin Operator, runtime class manager (kwasm for now), and spin-kube plugin. These project have their own release lifecycles; however, there are times in which certain features are only enabled in specific releases of each project are used. Users and marketplace offering maintainers will want to know when a new feature has been added to all the projects of SpinKube. One way to denote that is with SpinKube releases.

To give an example of why making it clear which versions of the projects are compatible, we can look at the OpenTelemetry (OTEL) feature. Support for configuring OTEL for monitoring Spin applications was added to the shim in `v0.15.0` and the ability to pipe OpenTelemetry parameters to the shim from a `SpinApp` was added in the Spin Operator `v0.3.0`. This means that people using the `v0.3.0` operator with a shim version less than `v0.15.0` may set OTEL details in their `SpinApp` to find that it is not configured in the app by the shim.

## Proposal

SpinKube will periodically provide releases. A release defines the release set of SpinKube projects. For example, SpinKube v0.X that brings in support for OTEL could be defined as:

- Shim / Node Installer: v0.15.0
- Operator: v0.3.0
- Kwasm: v0.2.3
- `spin kube` plugin: v0.3.0

> Note: a `spin kube` plugin version is specified even though it does not provide the ability to configure OTEL via the scaffold command. However, the output SpinApp can be updated with the OTEL fields. The `spin kube` version is provided to indicate the version that uses the same SpinApp CRD as the Spin Operator

SpinKube releases will not be cut at a certain cadence; rather, project maintainers may advise that a new release be cut upon the addition of new features.

The installation guide of the SpinKube documentation will display SpinKube release matrices and a features changelog. Marketplace maintainers can reference changes to this document.
Copy link
Contributor

Choose a reason for hiding this comment

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

What happens if the operator cuts a new release Y that has a feature F we want to explain on the docs. But, since we're on SpinKube release Z (which has a version of the operator Y-1) we can't explain the new feature F on the docs.

Copy link
Contributor Author

@kate-goldenring kate-goldenring Oct 31, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

The SpinKube releases document (say releases.md) will display the releases but the entire set of docs are not tied to a certain release. Ideally you'd be able to toggle the installation guides for each SpinKube release but i am not sure if our docs CMS supports that


In the future, we may also consider providing a "feature detection" Spin application that can be deployed to your cluster to determine which features your executor supports.

## Alternatives Considered

This could just be documented with compatibility matrixes (such as [this one](https://github.com/spinkube/documentation/pull/253/commits/e93aed2d5b30d2c220289572acc80b3dc4e4a448)).
Copy link
Contributor

Choose a reason for hiding this comment

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

My default is to prefer some kind of relative matrix - rather than only having "blessed" single-version-compatibility (because that's ~impossible in upgrades through in a real cluster, where you need old-and-new versions to be compatible for at least the duration of operator-shim-and-workload upgrades).

Could you expand on why you think this is non-viable (and expand on how we should handle upgrade compatibility?)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

By single version compatibility, do you mean all 4 projects releasing the same version number? That is not the proposal of this SKIP. The proposal is to add some marketing lingo on top of a matrix that says SpinKube 2.0 is shim 0.17, operator 0.4 etc