snap info <package> sometimes shows conflicting version info when using phasing/cohorts

[Thomas Parrott]

LXD snap packages are deployed using snap phasing and cohorts.

When a new LXD version is moved to the `latest/stable` snap channel our users sometimes report conflicting information is shown with `snap info lxd`.

An example is this:

```
summary: LXD - container and VM manager
publisher: Canonical✓
store-url: https://snapcraft.io/lxd
contact: https://github.com/lxc/lxd/issues
license: unset

services:
  lxd.activate: oneshot, enabled, inactive
  lxd.daemon: simple, enabled, active
  lxd.user-daemon: simple, enabled, inactive
snap-id: J60k4JY0HppjwOjW8dZdYc8obXKxujRu
tracking: latest/stable
refresh-date: yesterday at 17:19 UTC
channels:
  latest/stable: 5.5-37534be 2022-08-27 (23537) 113MB -
  latest/candidate: 5.6-794016a 2022-09-23 (23680) 142MB -
  latest/beta: ↑
  latest/edge: git-c76bc42 2022-09-25 (23689) 142MB -
  5.6/stable: –
  5.6/candidate: 5.6-794016a 2022-09-23 (23680) 142MB -
  5.6/beta: ↑
  5.6/edge: ↑
  5.5/stable: 5.5-37534be 2022-08-27 (23537) 113MB -
  5.5/candidate: 5.5-37534be 2022-08-19 (23537) 113MB -
  5.5/beta: ↑
  5.5/edge: ↑
  5.4/stable: 5.4-1ff8d34 2022-08-13 (23367) 108MB -
  5.4/candidate: 5.4-3bf11b7 2022-08-12 (23453) 108MB -
  5.4/beta: ↑
  5.4/edge: ↑
  5.3/stable: 5.3-91e042b 2022-07-06 (23270) 107MB -
  5.3/candidate: 5.3-b403e7f 2022-07-05 (23282) 107MB -
  5.3/beta: ↑
  5.3/edge: ↑
  5.0/stable: 5.0.1-9dcf35b 2022-08-24 (23541) 107MB -
  5.0/candidate: 5.0.1-9dcf35b 2022-08-19 (23541) 107MB -
  5.0/beta: ↑
  5.0/edge: git-13e1e53 2022-08-21 (23564) 113MB -
  4.0/stable: 4.0.9-8e2046b 2022-03-26 (22753) 71MB -
  4.0/candidate: 4.0.9-8e2046b 2022-03-24 (22753) 71MB -
  4.0/beta: ↑
  4.0/edge: git-407205d 2022-03-31 (22797) 73MB -
  3.0/stable: 3.0.4 2019-10-10 (11348) 55MB -
  3.0/candidate: 3.0.4 2019-10-10 (11348) 55MB -
  3.0/beta: ↑
  3.0/edge: git-81b81b9 2019-10-10 (11362) 55MB -
installed: 5.6-794016a (23680) 142MB in-cohort
```

The snap store at the time showed `latest/stable: 5.5-37534be` as the current version available, the same as the command output above. Although @stgraber had moved LXD 5.6 into the `latest/stable` channel by that point.

However we can see that for this particular user snap has recently automatically refreshed onto `5.6-794016a`.

This has caused some confusion and concern as the user wondered how it was possible that if the current `latest/stable` version was `5.5-37534be` how was it snap had apparently installed the version from `latest/candidate` without them switching channels.

Is it possible to get `snap info` to show consistent version information based on the phasing and cohort being used for the particular system?

[Maximiliano Bertacchini (maxiberta)]

> Is it possible to get `snap info` to show consistent version information based on the phasing and cohort being used for the particular system?

Phased releases lead to an inherent duality: clients are shown different "visions" of the same snap, either the old one or the new one, depending on the bucket they've been assigned and the current progress percentage. In this case, clients might get an update that's not yet reported by `snap info`. OTOH, if `snap info` returned a custom response to each client depending on their phasing bucket, as proposed above, different systems might still "see" differing versions of the same snap if they fall in different bucket, which is potentially confusing. Alternatively, `snap info` might show the in-progress release to all clients, assuming it'll eventually reach 100%. In this case, clients would see there's an update in `snap info`, but they might not get it even if they manually `snap refresh`, which is potentially confusing as well. But I think this approach might be a bit less confusing as it resembles the behaviour of `snap info` on non-progressively released snaps.

[Thomas Parrott (tomparrott)]

Agreed, there are multiple scenarios at play here.

It would be great if `snap info` can somehow indicate why a particular system is getting a more recent revision than is apparently available for that channel.

As we've had a number of confused users (both inside and outside of Canonical) wondering why they've ended up on a revision that is apparently not in the channel they are following. They end up thinking there is a snap bug whereby they are being delivered a revision from a channel they are not following (for example getting a revision that seems to be only available in `latest/candidate` when they are tracking `latest/stable`). Which is understandably concerning for them.

I don't think that having `snap info` showing different revisions for the same channel on different systems is anymore confusing than the reality that is occurring (that different systems are getting different revisions).

Perhaps it could show 2 revisions; published and effective?

[Thomas Parrott (tomparrott)]

Hi,

Was there any planned movement on this?

We just pushed LXD 5.17 to latest/stable and as happens most months some of our users are experiencing issues with some servers getting different versions than they were expecting.

Thanks