search

canonical / bundle-kubeflow

Charmed Kubeflow
Apache License 2.0
102 stars 49 forks source link

Standardize the ROCKs tags we use #747

Closed kimwnasptd closed 9 months ago

kimwnasptd commented 10 months ago

What needs to get done

Update our common action, if agreed, to build and publish rocks with a more readable image tag. https://github.com/canonical/charmed-kubeflow-workflows/blob/main/.github/workflows/build_and_publish_rock.yaml

My proposal is that this tag should just be <upstream-version>-<commit>. I.e. docker.io/charmedkubeflow/mlserver-mlflow:1.2.0-a3sd23

Why it needs to get done

Right now we are using different tags in some repos, that we used to build/publish images manually, and different in others. Here are some prime examples:

My main issue with the above are the use of the ubuntu version and the _1 at the end. IMO both of those introduce noise to the tag that is not very useful to know.

The git commit that the image was built from should be descriptive enough so that we can easily pin-point the exact version of the rockraft.yaml file that was used to build the image.

Edit by @ca-scribner: for background, the current version scheme and justification is defined in this spec

ca-scribner commented 9 months ago

Some open questions we need to close to implement this (they're in no particular order, but numbering them so they're easier to refer to later):

1. Will we ever publish the same image in multiple bases at one time?

Eg, mlserver-sklearn on both 22.04 and 22.10. If yes, how does our github/ci capture this in the proposed naming convention? I think yes we will hit this sometimes, not because we want to maintain two images generally but because any time we transition from one base to another we probably need a short overlap. For rocks, the base version is orthogonal to the software version itself (especially since we might advance a base to fix some CVEs) which feels important to capture.

in the OP's proposal, image mlserver-sklearn is named mlserver-sklearn:1.2.0-HASH where HASH is the rock repo hash at publish time. so if a publish ever has multiple bases, the versioning scheme breaks. How can we handle this case?

Possible solutions:

  1. use tag of <upstream-version>-<base>-<commit>. This probably requires some restructuring of this github repo or a branching strategy, like raised here
  2. use <upstream-version>-<commit>, but maintain this repo such that there is a separate branch for each supported base, ex gh:releases/22.04 and gh:releases/22.10, etc. Each branch's release is triggered separately (a change in the branch yields a release of just that branch), and then (I think) they'll always have their own unique commit hashes
    1. If we cherry pick a fix from one branch to another, do they receive the same commit hash (and thus one would publish over the other)? I don't think so?

2. Does it matter that rockcraft.yaml's version metadata is out of sync with the published version?

(raised this in rockcraft channel here)

the rockcraft.yaml file has a required version field that is for:

The ROCK version, used to tag the OCI image and name the ROCK file

We cannot put the commit hash into rockcraft.yaml because the commit hash depends on the file.

This version text does appear in the image (see RepoTags field in export from docker inspect here) - is there a consequence if we tag/push to dockerhub under a different tag? My gut says no but not sure

My guess is there's no real consequence to this being wrong, but we should confirm ). If this is really important, we could set version: PLACEHOLDER in our rockcraft.yaml files and then during publish time (after the commit hash is known) inject the commit hash into version

3. How can we easily confirm a metadata.yaml has the most up to date images?

With semver or similar, if we see CharmA's track/1.2 metadata.yaml points at myimage:1.2.3-0.1, it is easy to look at the corresponding rock repo's recent release (say myimage:1.2.3-0.2) and know we're behind.

If we version with commit-hash, this is non-trivial: it is easy to see if metadata's hash != rock repo's most recent hash, but it is hard to know if that matters. For example, a commit to an unrelated file in the rock repo would bump the hash but not mean should update your charm's metadata.yaml.

If we use commit hash in the rock version, what can we do to mitigate this?

ca-scribner commented 9 months ago

An alternative to using <upstream-version>-<commit-hash> would be having our own internal semver (ex: 1.2.3-0.2 would be our release 0.2 for upstream's 1.2.3). That would contain a bit more information at a glance (I can see 1.2.3-0.2 is probably better than 1.2.3-0.1) but has the same problem as the OP's proposal for multiple bases

ca-scribner commented 9 months ago

If we do go with pushing with a tag of <upstream-version>-<commit-hash>, I propose we write our rockfile.yaml like:

name: some-image
version: 1.2.3
...

where 1.2.3 is the version of the application being rocked, then our CI does the extra tagging just like this CI does already. We could also push the image with both VERSION and VERSION_COMMIT tags just to have an indication of what commit is the "latest" for a version

orfeas-k commented 9 months ago

Rebuilding from same commit

I think we should also account for cases where we may want to rebuild from same commit e.g. a package removed a CVE and just asks us to rebuild in order to remove it from our image as well. I remember us discussing this in the past. I don't think this should be part of the standard version since it's a rare edge case, but I think it's something we should decide during this discussion

Proposal

Adding a -<serial-number> suffix would be enough for this and it would be present only when needed e.g. <upstream-version>-<hash>-<serial-number(optional)>.

Question

Should this start from 1 or 2?

ca-scribner commented 9 months ago

For background, the current image version scheme was defined in this spec. Not saying we shouldn't change it because there's a spec, just that it adds context. iiuc, the current version scheme was modelled after the scheme used by other ubuntu images in the ubuntu dockerhub

ca-scribner commented 9 months ago

@orfeas-k that is a great point. If the ingredients that go into these images are mutable, that makes things much less clear.

ca-scribner commented 9 months ago

Agreements from an offline discussion: