prometheus versions in track 1 and 2 are incompatible so there is no way to switch tracks without data loss.
At some point in the future prometheus 2 will mature and I will be in a difficult position. I’ll want all new installs to use track “2”. At the same time everybody on track “1” should stay there.
My understanding is that above transition is not possible because as soon as I point “latest” at “2” everybody will be upgraded.
At the same time unless I point “latest” at “2” all new installs will be “1”, unless users explicitly choose track “2”.
Can somebody confirm my assumptions above?
Are there any workarounds or upcoming futures that will allow me to transition to prometheus 2 track?
I’ve run into this as well. As I understand it, latest is not simply a pointer, but a track unto itself. If you have a 2 track, and your latest version is 2, you need to release into both 2 AND latest if you want to “point” latest to 2 (which isn’t really pointing at all ).
I think what you need to communicate to your users is this:
Those who want to use v1 and STAY on v1, use track 1.
Those who want to use v2 and STAY on v2, use track 2.
Those who always want the latest, regardless of what that may be, use latest.
That of course doesn’t help the people who have already installed v1 from the latest track, and want to stay on v1. So what you really need are epochs.
As Kyle mentioned, you actually have 3 tracks: 1, 2, and “latest” (which is the default, and in which you currently have 1-series releases).
If 1.x is still active enough that you want that to be “latest”, then keep pushing 1-series releases to latest. It’s OK, then, to put the 2-series stuff into the “2” track for adventurous souls to try.
When 2 is mature enough to become “stable” and relegate 1.x to those who explicitly want to stay behind, there will be 2 conscious choices to make:
You need to choose when to push a 2-series snap to “latest” which as you said will cause people who are following “latest” to upgrade and lose their data As such, you must announce this as widely as possible and set a specific date when you will do the transition.
Once seeing this announcement, your users will have to decide whether they want to move ahead (no action needed, other than bracing for the data loss) or stay behind; in the latter case, they need to snap refresh --channel=1 prometheus, to switch to the legacy “1” track and stay there until they decide otherwise.
Here’s some more info on sample use cases for tracks, part 2 talks specifically about tracks and a use case similar to yours:
Other than that, Kyle’s explanations are right on target.
Part of the problem is that I don’t have a way to communicate the change. Anybody can download my snap without leaving contact details. On top of that the snap will likely run on many headless servers so even if I modified it to notify users on upgrade there is no guarantee they will see the message.
Breaking existing deployments is also very problematic, prometheus is a monitoring system so any data loss can have very significant impact on users and I really want to avoid that.
I’ll have a look at epochs, maybe they will help me with transition.
Yeah, wait for epochs before making the move, and simply don’t provide a snap that bridges between epochs. The people who have epoch 0 installed (the default, what people have installed now) will not have an upgrade path to epoch 1 unless you provide a snap with epoch 1*.
).
As such, you must announce this as widely as possible and set a specific date when you will do the transition.