New tracks for prometheus and prometheus-alertmanager snaps

[rick_h]

@roadmr

I’m also not clear about why this track naming is needed for an ostensibly non-system-related snap.

The Ubuntu Server team is working to help provide updates to these snaps in the LMA stack as they are the best delivery mechanism. These snaps work in conjunction with deb software as part of the LMA stack and are tested together so we’re looking to have a track that users on a server can follow and be assured their LMA across systems will continue to work. Server users are used to tracking software by LTS release and the software version can be less important than “tested to work with 20.04” and “tested to work with 18.04”.

@roadmr

Can you detail how these application snaps are used as “bases” for OCI images? (note that the concept of base is well-defined in the snap ecosystem, so if you mean something else, it might be better to revisit your nomenclature to avoid confusion).

The server team is attempting to support and stand behind the version of software across the delivery artifacts. In this case, the same versions in the snap series-based tracks will be used to build docker containers of the same versioned software and treated as equal ways of getting and running a piece of software. It’s more important for us to have the tested version of prometheus that works in the LMA stack across distro, snap, and docker container.

Our plan is to stand behind the versions and treat them a bit like an LTS moniker. You could say the tracks are intended to help declare a LTS track to users. Since there is more than one LTS at play at any given time we can’t just declare a single LTS track, but instead are matching the series up as the reference points. These LTS tracks will be working with security and server to have updates and be supportable over a length of time.

@roadmr

Do you have any documentation or precedent on naming other non-system-essential snaps according to the release, like this? (I believe some kernel snaps do follow that nomenclature, which again is because when building an Ubuntu image, the kernel version is strongly tied to what the rest of the image will need/ do - but as I said that doesn’t seem to be the case with prometheus).

I think this is where I disagree. Since these snaps need to function as part of a system and that system is based on the image at play, having something kept in sync is applicable. The telegraf deb package needs to be tested against the prometheus version with the grafana version and other tools in the LMA stack. We’re attempting to bridge different artficats into a single system.

@roadmr

Normally, ubuntu-version-named tracks are used for snaps that, themselves, are dependent on something on that particular Ubuntu Core release, especially kernel or gadget snap features, stuff that can’t be solved simply by using a different base on the snap (say if your snap depends on Core 20, you can use base: core20 for those features to be available even on a Core 18 system). This doesn’t seem to be the case with prometheus and alertmanager.

This is true, it’s less about dependant on the system and more about support and testing matrix. Since we’re testing 20.04 with the versions of the snaps in those tracks and committing to backporting things like security updates into the snap in that track it’s similar to the story of keeping a set of things working together.

@roadmr

If the intent is to “pin” or “freeze” specific revisions of the snaps to use when baking an image, that sounds like a fair use case, though in that case I would consider a track name that more clearly indicates the purpose (20.04-image-building). The example is a bit unwieldy but:

It’s not so much for image building (though it is used for building a docker container) but is about committing to a stable version much like we do when we select a LTS supported version in an Ubuntu LTS release. We cannot commit to security patch and test every version of prometheus/prometheus-altermanager and so we commit to a longer support window for security purposes to a given track.

Really this is about the server team committing to specific LTS version of a piece of software and the latest might move on but that doesn’t mean you will get the same support for what’s in latest as you would for 20.04.

I appreciate this is something new/different as the server team has not previously stood behind snaps that it’s working with and suggesting as a solution for users in documentation such as the Ubuntu Server Guide. However, this is something we’d like to work together to find a standard pattern around and follow as we attempt to support and recommend snaps in production server environments (or production docker deployments) going forward.