Hi! Thank you for sorting this for us.
Could we have the same for the grafana snap please, as another component of the server team’s LMA stack, now that we have established this pattern? This one is currently being maintained by @aluria and we have been coordinating with him; he can provide an ack if required. Tracks and names would be the same as for Prometheus please: 20.04 and 21.04.
+1 to align with the prometheus and prometheus-alertmanager snaps by adding the 20.04 and 21.04 tracks in the grafana snap, too.
Thank you,
-Alvaro.
I moved this request from New tracks for prometheus and prometheus-alertmanager snaps to keep things separated. Just because the track pattern being requested is the same doesn’t mean that the same criteria apply, and it is a different snap with an entirely different maintainer.
As with prometheus and friends, Grafana has existing tracks that actually designate Grafana versions. Allow me to express my concern again that the track pattern will be confusing to users who will think they must install 20.04 grafana on Ubuntu 20.04, and these snaps are not really system-dependent which is the usual pattern for ubuntu-version-named tracks, though I have expressed this in the other thread and there’s little value in repetition.
I’m also still unsure why you don’t bundle all these tightly-coupled components as a possibly single ubuntu-lma snap which would allow the individual pieces to exist with their current track nomenclature while still being shipped as a single entity as part of a unified stack.
I think this will result in complexity trying to match the components and confusion for users.
Assuming you’ve read the prometheus thread and heed the above concerns, and still want to go ahead, I’m a reluctant +1 to grant these tracks - in this case having established the pattern has a definite “the ship has sailed” feel.
Since this is a different snap, I would like @reviewers to chime in on this request - the simplified process is not directly applicable from the prometheus decision since it’s a different snap, and as happened there, the track pattern is different enough that I also would prefer the extra validation.
Thanks for the feedback. I’m trying to sit down and think through this to help make sure we’re doing the right things for the right reasons. A couple of questions.
I assume tracks are less utilized and used with intent. You get onto a specific track for a specific reason. By default, folks pull from latest until they move off for a specific purpose? In this way, they wouldn’t feel they have to use a specific track but would see it as available when they hit a need.
This is interesting. I’d not considered a single snap just given that sometimes things need to be updated and you’d roll the how set of software for this. You could also split work such that grafana is on another host with internet access while prometheus is done in HA only on internal networks. The other consideration is that telegraf feeds data to prometheus/grafana and is a deb based component to the system. We looked at making telegraf a deb but given the nature of the software to read system details it would never be confine-able and people write custom scripts/collect custom data which we thought might make it a poor choice to deliver as a snap.
For docker container artifacts we are create tags/tracks of $majorversion_series and I do wonder if that pattern might be better here in an effort to clarify beyond the series support/testing matrix what’s actually in the snap. The goal from our point of view is to state that the track is safe for the life of series X and won’t have dramatic changes that could break production server deployments.
Would tracks of version1_20.04 and version3_21.04 change your concerns with the tracks as a whole?
Thanks for replying 
This is correct in the majority of cases. Ideally latest is what most people should be using, and folks shold only explicitly choose a track for a reason such as "latest now has the most recent postgres but I want 9.3 because I depend on a 9.3 feature which doesn’t work on later releases".
Having ubuntu-release-named tracks, as I mentioned, is also a common pattern, but (and this is the main source of my worries) we tend to reserve it for snaps that really, actually depend on something provided by the base system which means a particular revision of the snap won’t work with other Ubuntu releases. If it’s not a feature provided by the base system, you’ll agree a better fit would be to use a different base that provides the base files a snap would need. An example is network-manager which IIRC is very tied to the features of the specific kernel it runs on.
Right, this is a good point for having them as separate snaps.
Mostly yes, what I’d like to see is some indication in the track name that will disambiguate whether “I need to install the 20.04 snap if I’m using ubuntu 20.04”.
Regardless, I’m OK with going with the pattern that was originally requested - at this point consistency with prometheus is also something to keep in mind, and as long as the snaps’ maintainers are aware of these concerns and are ready to help steer people if confusion arises, I think we’re good to go.
Same as prometheus, for consistency purposes, +1.
I’ve created 20.04 and 21.04 grafana tracks.
