Channel fallback terminology and behavior

snapd
1

Regarding terminology, let’s find a word, then.

We started using “fallback” for the case where the channel is actually changed (think about a package installed from “stable/hotfix3” that at some point needs to change the channel and keep working with “stable”).

The case discussed in this post, where (for example) “beta” doesn’t have really any release in it, but shows the one for other less-risky channel is different, because there’s no change between channels from the client POV.

Of course, we could start calling “fallback” to what we previously called “tracking”, but we would need to find another word for the “fallback” behaviour I explained above.

2

Those cases seem to be exactly the same to me. We never change a channel on the client end. The client may be using a channel that is closed and hidden, and which may have a fallback or not, but we won’t simply change it.

3

Are you saying that “branches” should mimic the behaviour of “fallback” (previously called “tracking”) rules between standard risks?

For example, we currently have for standard risks:

  1. have a channel map with beta=5, candidate=6
  2. “snap install” from beta
  3. beta is closed
  4. “snap refresh” would make snapd query for “beta”, and Store would answer “beta is at revision 6” (because it’s closed and because of fallback rules it would follow candidate).

And you say that branches should behave the same way? to be explicit:

  1. have a channel map with stable=5, stable/hotfix=6
  2. “snap install” from stable/hotfix
  3. a revision 7 is released to stable
  4. stable/hotfixes expires
  5. “snap refresh” would make snapd query for “stable/hotifx”, and Store would answer “stable/hotfix is at revision 7” (because it’s no longer there so it fallbacks to “stable”).

Thanks!!

4

I’ve split this discussion out of the previous thread since this is a slightly orthogonal conversation and interesting on its own.

So, yes, those two scenarios you presented sound great, but let me outline a more comprehensive description of what seems to be a good place for us to be in:

  1. Any channel may be open or closed
  2. Any channel may have a fallback setting defined, which means once closed it causes the client to observe the tip of a different channel as its own
  3. When a channel does not have the fallback setting defined it behaves the same as if no snaps were ever published there
  4. The client never changes the channel without an explicit administrator action doing so
  5. As a matter of policy (rather than implementation), there is no fallback across different tracks, because the whole point of tracks is to give the user a chance to opt into a well defined and disjoint sequence of revisions
  6. Tracks may be hidden, which imply clients can still use the channels in them, but should refrain from doing so since these tracks are going away; this does not affect the fallback behavior described above, and is merely a way to drive a track out of use without disrupting service

How does that sound?

5

Agreed in general, let me express a couple of comments…

  1. Yes, considering “closed” also the channel that never got any release on it (which sounds great, but may be a little confusing as the developer never did the “close” action on them).

  2. That flexibility is not (currently) in place, the rules are hardcoded: the risks fallback always to the immediate more stable one (taking in consideration that “stable” doesn’t fallback to any other risk), and branches fallback to “stable”.

  3. As per what explained before, the channel can not miss a definition about this

  4. Perfect.

  5. Perfect.

  6. Awesome, but one question: a channel from a “hidden” track would be used normally, but will not appear when doing “snap info”, right? Also, at the moment of the user using a hidden track, she should be somehow notified?

Thank you!!