Snap module does not change channel if the snap is already installed

[sean-abbott]

SUMMARY

I'm attempting to set the snap channel with ansible on already installed machines, but "tracking" channel (which happens to currently co-incide with the version I'm tracking to track) remains pointed at latest/stable

ISSUE TYPE

• Bug Report

COMPONENT NAME

snap

ANSIBLE VERSION

ansible 2.10.4
  config file = None
  configured module search path = ['/home/sean/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/sean/.local/pipx/venvs/ansible/lib/python3.8/site-packages/ansible
  executable location = /home/sean/.local/bin/ansible
  python version = 3.8.5 (default, Jul 28 2020, 12:59:40) [GCC 9.3.0]

CONFIGURATION

OS / ENVIRONMENT

NAME="Ubuntu"
VERSION="20.04.1 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.1 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

STEPS TO REPRODUCE

- name: install microk8s snap latest
  become: yes
  community.general.snap:
    name: microk8s
    classic: yes
    state: present

- name: install microk8s snap
  become: yes
  community.general.snap:
    name: microk8s
    classic: yes
    channel: 1.20/stable
    state: present

EXPECTED RESULTS

I expect the tracking channel of the microk8s snap

ACTUAL RESULTS

The tracking channel for the microk8s snap remains set to latest/stable

[ansibullbot]

Files identified in the description:

• plugins/modules/packaging/os/snap.py

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibullbot]

cc @angristan @vcarceler
click here for bot help

[russoz]

@sean-abbott snap itself (the CLI tool, not the ansible module) does not do that, so IMHO this should be an optional feature, perhaps something akin to a "force" flag that will attempt to identify these cases and, if necessary, remove the previous version from the previous channel and install the package from the specified channel in its place.

[strk]

I'm having the same problem, current snap CLI can do this via:

snap refresh --channel <otherchannel> <package>

[ansibullbot]

Files identified in the description:

• plugins/modules/snap.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[alirezaghey]

@russoz I'm having the same issue. As mentioned by strk, this is implemented by snap. One major use case is how Canonical's MicroK8s is upgraded. K8s versions are channels and you upgrade a minor version, say from 1.26 to 1.27, by running:
snap refresh microk8s --channel 1.27/stable.
I'm currently doing this using shell, which is a last resort.
IMHO, this would be a good addition to the module. I'm a total newbe with Ansible, but have some experience with py and with some guidance could have a look at that if it's generally accepted.

[russoz]

hi @alirezaghey your message got me thinking of this problem and it itched up to the point where I decided to do some work on it. The PR I created makes changes to the code so that the snap module is now able to recognize that an installed snap from one channel is not equal to a snap being installed from a different channel.

[russoz]

Now the problem is, what to do with that? :-)
I see some options (feel free to add more):

1. silently refresh the installed snap to match the requested channel
2. add a "refresh" or "update" state to the module, so installing with a different channel would fail if previously installed
3. add a "force" or "force_update" bool parameter to the module - when that flag is true, then it behaves like 1, otherwise it behaves like 2

What you folks think?

BTW, after this PR I am planning on doing a big refactor on the module - should not affect its outcome, and create a snap_info module to read the installed snaps.

[alirezaghey]

hey @russoz, that's a nice addition!

IMO, it would be best to stay as close as possible to the snap CLI. I haven't investigated the snap CLI, so the below are just assumptions that it would work like this:

1. Have a "refresh" or "update" state, (preferrably "refresh") to stay true to the naming convention of snap itself, which is false by default.
2. When false, the snap module acts like the snap install command.
3. When true, the snap module acts like the snap refresh command.

We would need to look into how snap reacts to snap refresh previously_uninstalled_snap or snap install previously_installed_snap --channel but_same_old_channel/stable etc. stuff.

This would keep working with the module easier. But again, I'm not very familiar with Ansible and its conventions, and it could be that staying this close to how the original tool behaves isn't part of the philosophy.

[russoz]

hi @alirezaghey that sounds like option 3 up there. I like it too, but let's give a bit of time for others to take a look.

[russoz]

Hi @alirezaghey I have worked on it this weekend and I've been thinking that it would make more sense, in the spirit of ansible's idempotency, to have the module automatically detect whether a refresh is needed or not and act accordingly.

I have just updated the PR with that, and I have added a test case to demonstrate. The CI is still running but it looks good (it tested ok locally).