Managing cohorts

The store is growing the capability of capturing a view/snapshot at a given point in history of the channelmap for each of a set of snaps, called a cohort, fixing a corresponding set of revisions for those snaps given other constraints (e.g. channel, architecture). The cohort is then identified per snap by an opaque key that works across systems. Installations or refreshes of the snap using a given cohort key would use the fix revision for a up to 90 days period, after which a new set of revisions would be fixed under that same cohort key and a new 90 days window started.

There is a small UX challenge in that we expect cohort keys to be somewhat long (>80 chars long). While we should not make the feature unapproachable for human users, we would typically expect it to be driven by software/scripts.

The following features will be implemented in snapd 2.40.

Installing or refreshing a snap in a cohort by key

snap install --cohort=<cohort-key> <snap>
snap refresh --cohort=<cohort-key> <snap>

This would work like --channel in that the cohort key would also become sticky for the given snap. Most other install/refresh options can be combined with this except --revision.

Leaving/changing cohort

To stop snap from belonging to a cohort for subsequent operations:

snap switch --leave-cohort <snap>

To both stop a snap from belonging to a cohort and refresh it outside of it:

snap refresh --leave-cohort <snap>...

Changing cohort for subsequent operations:

snap switch --cohort=<cohort-key> <snap>

Creating a cohort for snaps possibly not yet on the system

snap create-cohort <snap-name>...

Output would be YAML-parseable of the form:

cohort:
    <snap-name>:
       cohort-key:  <cohort-key>
…

This is does not directly affect the state of the system.

Querying about cohorts

snap info will show whether the snap on a system belongs to a cohort (in-cohort will be mentioned in the notes on the installed entry). snap info --verbose will also print the cohort-key when set.


Future work (not planned for 2.40):

To find out what a snap would refresh to in a cohort this can be used:

snap refresh --list --cohort=<cohort-key> <snap>
2 Likes

@chipaca has suggested for a slightly less bare-bone experience to use a level of indirection naming cohorts and using a registry for cohorts under ~/.snap/cohorts. Given that cohorts are most interesting across machines we would need to consider some form of import/export.

@pedronis could the snap download command be mentioned here, as well, please?

That is a possible extension, but I wonder how would you plan to use snap download and cohorts together? do you do asserted installs of what is downloaded? if you download once and distribute the same snap across the cluster is not clear you need cohorts at all. The point of cohorts (together with refresh.hold possibly) would be indeed to just be able to do normal installs instead of that.

One use case for snap download to support cohorts is for building a set of images that all have the same snap versions, even if they’re built at slightly different times and on different architectures.

3 Likes

Yes, we need it exactly for that.

This is now coming in 2.40.

How do cohorts work with reverts? If during the install of cohorts one of the snap installs fails do all the snaps roll back to the previous revision?

Also, can you go backwards in time to a previous cohorts? I.e. I install with cohort A then refresh to cohort B successfully, can I go back to cohort A? Is this just subject to the 90 days restriction?

Revert is purely a local operation always targetting an implicit/explicit revision so there is no cohort in play. In other respects vs undos the cohort setting of a snap should behave the same as the channel one.

yes, if cohort A hasn’t gone over the 90 days window, after which point a new window starts that could overlap with newer B window.

1 Like

Cohorts are tailor made for the use-case where the lifecycle of the snap is managed externally, such as by a Charmed Operator or manually by an sysadmin, especially where upgrades need to be coordinated across multiple machines. It complements well the option for the snap to self-manage its upgrade via the gate-auto-refresh hook for the other use-cases, such as Desktop applications, tools like microk8s or multipass, IoT devices, etc.