Ansible.posix: [mount] Ability to temporarily mount a filesystem without altering /etc/fstab

An additional use case discussed in the issues and PRs opened previously (2571, 19820, 48134) over the last 5 years, and one I am currently facing, is the need to temporarily mount a filesystem that is already configured in fstab. Currently the mounted state requires that 'src' be provided, which is reasonable if updating fstab is required, but should be optional if a valid entry already exists in fstab.

For example, if I need to add filesystems to a server and migrate existing content without changing the directory layout, I might have a playbook that creates the filesystems and mountpoints in their final desired state but does not actually mount them yet. Then I might have a playbook to mount them in a temporary location, migrate existing content to the new filesystems, and then unmount the temporaries and remount them in their new, permanent location.

See https://github.com/ansible-collections/ansible.posix/issues/107.

It would probably be clearer to separate configuration and running state, and split them into two module parameters, the same way it is done for service or systemd modules, with state to describe the wanted running state of the service (started/stopped/restarted), and enabled to describe the wanted persistent state of the service: enabled at boot or not.

Mounts could be managed the same way, with (at least one of these params required):

    state: mounted/unmounted/remounted
    enabled: yes/no  # configured in fstab, or not

For me, the current choices for the state option aren't obvious: the differences between present, absent, mounted and unmounted need I read the docs very often. present is not the opposite of absent, and unmounted is not the opposite of mounted. And with these four states, we are even not able to just get an active mount without modifying fstab.

So I agree that the module needs some boolean param to deal with fstab, but I think enabled would be more consistent than modify_fstab, and the state option should be refactored in the same time (to not make complicated things such as "enabled is ignored when state=absent or state=mounted (or sate=present too, maybe)").

Don't really see why the previous issue was closed, looked like there was good discussion there. The ansible core team's argument that it means the "mount" module has too many options doesn't seem like a very convincing argument given modules like ansible.builtin.file.

A part of the trouble with the state option of this module, is that two of its values describe (or lead to) the same state, but depend on the initial state.

• When starting from state=absent (that is the opposite of state=mounted), with state=present, fstab is configured but the mount is not actually mounted.
• When starting from state=mounted, with state=unmounted, the mount is unmounted but fstab is left configured, that is very close to the previous result.

But when doing the same from state=absent to state=unmounted, or from state=mounted to state=present, nothing happens, that means in that cases state=unmounted and state=present lead to opposite results (since absent is the opposite of mounted, and nothing has changed).

This makes clear for me that there are two things to control separately: the current mount state, without worrying about fstab contents (as does state=unmounted); and the fstab contents, without worrying about current mount state (as does state=present). Maybe another state (state=active ?) would be sufficient to cover the need of mounting a device without modifying fstab, but state values are already confusing enough in my opinion.

On the other hand, moving to split an option into two options by keeping its name in the new set may be confusing too, and needs probably more work (deprecation step, etc). Anyway, it seems to be a better target. That would migrate this way:

• old state=present --> new enabled=yes + state=None
• old state=mounted --> new enabled=yes + state=mounted
• old state=unmounted --> new enabled=None + state=unmounted
• old state=absent --> new enabled=no + state=unmounted (or keep state=absent for mountpoint removal ?)

other ideas ?

I'd be fine with quidame's suggestion if it is the easiest non-breaking solution.

For consistency with service/systemd, however, I would personally prefer to have the end goal of:

• state=present meaning "_mounted_", state=absent meaning "_unmounted_"
• state=remounted dropped in favor of a force (or perhaps force_mount) option
• enabled=yes meaning "_present in fstab_", enabled=no meaning "_not present in fstab_"

Something like this:

• enabled: [ yes | no ] - Requires src, path, fstype. Ensures fstab is configured appropriately for the requested mount.
• force: [ yes | no ] - Requires state.
  
  
  
  • If state=present, equivalent to current state=remounted behavior
  
  
  • If state=absent, equivalent to umount -f <path>
  
  
• state: [ present | absent ] - Requires path. No longer a required option if enabled is defined.
  
  
  
  • If present, and src and fstype are NOT defined, equivalent to mount <path> (which will only succeed if the entry is already in fstab), otherwise equivalent to mount [-o opts] -t <fstype> <src> <path>.
  
  
  • If absent, equivalent to umount <path>.
  
  
  • Deprecate mounted: now equivalent to present - but continue current behavior of also updating fstab unless also enabled=no
  
  
  • Deprecate unmounted: now equivalent to absent - but continue current behavior of also updating fstab unless also enabled=yes
  
  
  • Deprecate remounted: recommend using force for this instead - but continue current behavior of attempting remount
  
  

I admit I have not looked at the code and do not know if my suggestions would be onerous to implement. However, this would also cover my additional use case of ensuring that a previously configured mountpoint is actually mounted, without needing to know all of its details (i.e. src and fstab) if they are already present in fstab.

If adding the additional force option introduces too much complexity, then leaving state=remounted as a valid (non-deprecated) option is OK.

Because Dev team couldn't update this feature, I use another workaround

- name: "Mount ISO CentOS"
  mount:
    path: /mnt
    src: "/tmp/centos.iso"
    fstype: iso9660
    opts: loop
    state: mounted
    fstab: /tmp/tmp.fstab

- name: "Mount ISO CentOS"
  mount:
    path: /mnt
    src: "/tmp/centos.iso"
    fstype: iso9660
    opts: loop
    state: unmounted
    fstab: /tmp/tmp.fstab

Use a fake/temp fstab file.

Hah, that's neat. So once done with the mount, is it ok to simply unmount and delete tmp.fstab?

Hah, that's neat. So once done with the mount, is it ok to simply unmount and delete tmp.fstab?

Yes :)