Questions about releases/versioning

[Max Gautier]

Hello,

I'm trying to understand the releasing/versioning scheme used by gvisor.
I'm reading the documentation at https://gvisor.dev/docs/user_guide/install/#versions ,
which say to look at https://github.com/google/gvisor/releases. But
AFAICS, there is no releases published on Github.

I see that there is lots of 'release-***' tags published every week, but
given these are date-based, I understand it's basically a snapshot of
the master branch at that date ?

For context, I don't use gvisor directly, but I maintain Kubespray[1]
which allows user to install it, and I'm currently reworking our
"version updating" mechanism.
For gvisor, it's not clear to me what versions we should include (by
"include", this only means we record the hash so the users deploying it
have some supply-chain integrity).

For now, I'm using the below GraphQL query on github to get the
versions ; if anyone has some guidance or link to documentation for a
better way (or if somehow this is, in fact, ok for gvisor), I'll
appreciate it !

Thanks

[1]: https://github.com/kubernetes-sigs/kubespray/

The graphql query:
```
query($repoWithReleases: [ID!]!, $repoWithTags: [ID!]!) {
with_releases: nodes(ids: $repoWithReleases) {

# ... For other stuff with releases
}

# This for gvisor
with_tags: nodes(ids: $repoWithTags) {

... on Repository {
nameWithOwner
refs(refPrefix: "refs/tags/", last: 100) {
nodes {
name
}
}
}
}
}
```

--
Max Gautier

[Zach Koopmans]

Hey Max,

The tags are the releases. We have some internal release mechanisms that kick off releases. There some internal Google stuff that gets packaged in a packaging system, and a workflow that tags the commit ID in GitHub to mark the release as well as build artifacts for the release. The internal release and external tag are identical, so the same CI is used for both.

Not the most standard way of releasing, but it has worked for us so far.

Our internal system is also a mono-repo, so this is why you see tags on master being it and not version branches. The current mode benefits from some massive internal scale and monitoring, which helps the stability of the project overall.

The current system could of course be improved on, and if you have thoughts on what you'd like to see, that would be welcomed. Taking releases from only master and version branches probably won't happen anytime soon due to the scale previously mentioned, but we're happy to consider other improvements.

Zach

[Max Gautier]

Hi Zach,

I don't mind non-standard, as long as I can make sense of it (and
preferably do some automated decision). What I couldn't find for gvisor
was mostly "What does a version bump mean"
For instance:
- if the gvisor configuration/setup change, would that be noticeable in
the version number ?
- other "breaking" changes ?

For context, in kubespray we upgrade somewhat automatically for the
default versions of component we ship to the last patch releases. If I
had the way to distinguish the same thing for gvisor I'd be happy.

Merry Christmas o/

> --
> You received this message because you are subscribed to the Google Groups "gVisor Users [Public]" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gvisor-users...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/gvisor-users/8d10f2ca-1028-4d6a-a5d7-038ae741838bn%40googlegroups.com.


--
Max Gautier

[Zach Koopmans]

I don't mind non-standard, as long as I can make sense of it (and
preferably do some automated decision). What I couldn't find for gvisor
was mostly "What does a version bump mean"

Interally, our releases are simply a snapshot of the code on "master" (uni-repo w/ no branches) at a given time. For us, this is usually our Monday candidate (5 candidates per week). So externally, that just looks like a tag

on master at a given time, hence the numbers: release-20241217.0 -> December 17, 2024

- if the gvisor configuration/setup change, would that be noticeable in
the version number ?

WRT k8s, the interface is the containerd-shim for gVisor, which very rarely, if ever, changes. I think the last change we made to it was to add some guts for port-forward support, which didn't change anything else. What may change is some flags in runsc, but those mostly will be additions and really only affect you if you're using flags in the shim.

We are constrained internally by GKE support, which as we speak, supports 1.27 - 1.32 k8s versions and uses containerd 1.7.X. We test heavily on GKE.  

If you want to see the changes between each version, a "git log tag1 tag2" is an option.

- other "breaking" changes ?

git log/diff is your best bet here for changes. Normal bugs will of course happen like any other software. But wild changes in the setup on k8s with the shim won't. We're constrained by the OCI spec for container runtimes (e.g. runc, kata) here...we don't define this ourselves.

For context, in kubespray we upgrade somewhat automatically for the
default versions of component we ship to the last patch releases. If I
had the way to distinguish the same thing for gvisor I'd be happy.

Our internal testing on GKE works are the following:

- Presumbit/continuous/release tests that 1) install runsc and the shim and 2) run a bunch of pods against those versions.

- The pods we run are anything from basic busybox bash commands to an nginx server to some NVIDIA GPU pods.

- eperot@ is in the process of open sourcing some of our benchmarks and tests on k8s: https://github.com/google/gvisor/tree/master/test/kubernetes. These use the same methods.

I'd advise some thing similar, if less robust, for your needs. Automated updates can be to just search the tags in the repo and pick the latest one. If something breaks, I'd

- Check git log/diff

- Check if flags have changed in runsc (command in runsc: "runsc flags")

- File a bug.

Hopefully this answers your questions, but I'm here if not. :)

Hope your Holidays were awesome!

Zach

[Max Gautier]

Thanks, I can work with that ; we'll use the latest tag, that should do.

Our gvisor setup in CI does not work at the moment, and we have an old
version (hence the work on upgrade automation).
But once we get running (again), that should be good enough.

Happy new year o/

On Thu, Jan 02, 2025 at 11:07:55AM -0800, 'Zach Koopmans' via gVisor Users [Public] wrote:
>
>
>
> *I don't mind non-standard, as long as I can make sense of it
> (andpreferably do some automated decision). What I couldn't find for
> gvisorwas mostly "What does a version bump mean"*

>
> Interally, our releases are simply a snapshot of the code on "master"
> (uni-repo w/ no branches) at a given time. For us, this is usually our
> Monday candidate (5 candidates per week). So externally, that just looks
> like a tag
> on master at a given time, hence the numbers: release-20241217.0

> <https://github.com/google/gvisor/releases/tag/release-20241217.0> ->
> December 17, 2024
>
>
> *- if the gvisor configuration/setup change, would that be noticeable inthe
> version number ?*

>
> WRT k8s, the interface is the containerd-shim for gVisor, which very
> rarely, if ever, changes. I think the last change we made to it was to add
> some guts for port-forward support, which didn't change anything else. What

> may change is some flags in *runsc*, but those mostly will be additions and

> really only affect you if you're using flags in the shim

> <https://gvisor.dev/docs/user_guide/containerd/configuration/>.

>
> We are constrained internally by GKE support, which as we speak, supports
> 1.27 - 1.32 k8s versions and uses containerd 1.7.X. We test heavily on
> GKE.
>
> If you want to see the changes between each version, a "git log tag1 tag2"
> is an option.
>
>

> *- other "breaking" changes ?*

> git log/diff is your best bet here for changes. Normal bugs will of course
> happen like any other software. But wild changes in the setup on k8s with
> the shim won't. We're constrained by the OCI spec for container runtimes
> (e.g. runc, kata) here...we don't define this ourselves.
>
>
>

> *For context, in kubespray we upgrade somewhat automatically for thedefault
> versions of component we ship to the last patch releases. If Ihad the way
> to distinguish the same thing for gvisor I'd be happy.*

>
> Our internal testing on GKE works are the following:
> - Presumbit/continuous/release tests that 1) install runsc and the shim and
> 2) run a bunch of pods against those versions.
> - The pods we run are anything from basic busybox bash commands to an nginx
> server to some NVIDIA GPU pods.
> - eperot@ is in the process of open sourcing some of our benchmarks and
> tests on k8s: https://github.com/google/gvisor/tree/master/test/kubernetes.
> These use the same methods.
>
> I'd advise some thing similar, if less robust, for your needs. Automated
> updates can be to just search the tags in the repo and pick the latest one.
> If something breaks, I'd
> - Check git log/diff

> - Check if flags have changed in runsc (command in *runsc*: "runsc flags")
> *- *File a bug.

> To view this discussion visit https://groups.google.com/d/msgid/gvisor-users/8675586f-7889-4818-af2a-b39745935e89n%40googlegroups.com.


--
Max Gautier