I would like to request the creation of new tracks for the prometheus and prometheus-alertmanager snaps. These snaps are being used as the base for the Ubuntu OCI images, which will be updated for every Ubuntu release. Therefore, we’d like to keep track of the snap versions used to build each OCI image, for each Ubuntu release.
The track names I would like to request for both prometheus and prometheus-alertmanager are:
(We have not updated the images for Groovy, that’s why I’m not requesting a track for 20.10).
Please let me know if you need more info and I’ll be happy to provide.
Currently prometheus has 1 and 2 tracks, which signify the major versions of prometheus they provide.
The 20.04/21.04 tracks unfortunately deviate from this convention and my main concern is that they will be discoverable, and thus confusing, for users. I’m also not clear about why this track naming is needed for an ostensibly non-system-related snap.
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).
Can you also explain why a different version of prometheus and alert-manager is needed for each version of Ubuntu? can’t they just use the same one?
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).
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.
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 will be used by an automated process so it doesn’t matter if it’s uncomfortable to type, as you won’t do so very often.
It’s clearer for end-users. “I don’t need this because I’m not building a 20.04 image”, versus “oh this track is named 20.04, and I have Ubuntu 20.04, I need to install this” (to reiterate, doing so would negate a benefit of snaps in that you don’t usually need to concern yourself as to which track or version of a snap works with your Ubuntu system).
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”.
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.
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.
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.
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.
I still think the track naming is awkward, particularly since you said it’s mainly meant as a version for the LMA stack - there’s always the possibility of a new LMA stack coming out in, say, 21.06, and that will be super confusing. Alternatively, if you always publish versions of snaps that work well together to the 20.04 track, that ties the releases conceptually to 20.04, when the thing might work just as well with 18.04 as a base (and I don’t think it would be a very high cost for you to test on both releases).
The above makes me wonder why, if such tight coupling is needed, a single snap containing everything (even other snapped components as stage-snaps) isn’t produced instead of trying to painstakingly align components using tracks in a way that feels like it tries to mimic non-snap packaging systems.
Having said all of the above - since we do have good precedent with snaps using ubuntu-version-named tracks, and as long as you’re aware of the potential confusion for users of this snap with the somewhat inconsistent track naming (some tracks serve a purpose, others serve a different purpose), I’m +1 to granting the tracks as requested (20.04 and 21.04).
That said, I can see where a confusion might arise. For example, could someone on ubuntu 20.04 install the snap from the 21.04 track? Or vice versa? Will the actual content be identical, frozen to the track creation time, or could it even happen that 20.04 has “newer” components than say 21.04?
It can’t be possible to have 20.04 with newer components than 21.04. Since software is ever moving forward. The general idea is that we’re focusing on a supported version for a series of time and so primarily expect that folks can rely on something in the 20.04 track to work with 20.04 and to be supported for the same time window as the rest of 20.04. I appreciate the potential for confusion, but for folks in this world it’s easier than knowing that the postgresql 10 track is considered LTS and supported for the life of 20.04 while the postgresql 11 track isn’t.
Now could someone install whatever track they want, sure thing. Nothing is preventing it. But it’s beyond our ability to test, fix, and support all combinations on all different series of components deb/snap/container so we’re focused in on series-based slices of supported and validated sets.