Design discussion: MountRes

[ffrank]

For addressing #525 I proposed a patch that removes fstab support in favor of creating unit files per mount. https://www.freedesktop.org/software/systemd/man/latest/systemd.mount.html discourages fstab wrt. tooling. But then of course, config management aims to insert itself seamlessly in manual workflows, so I see the point in holding on to fstab as well.

I could see it work as follows:

mount "/var/lib/docker" {
    state => "exists",
    device => "/dev/sdk12",
    persist => none | fstab | /etc/systemd/system,
}

[purpleidea]

Okay here are some abridged comments from the PR:

1. fstab support-- I actually think that is still valuable to have, at least for now-- so how do we handle that? Do we have a separate resource? Do we have it be an optional for this resource? Do we have mount:systemd and mount:fstab ? Also see...

2. Is the systemd variant of this resource (as shown here) similar enough to the svc resource that they should just be combined there? I think architecturally they're quite similar. I would need to investigate more.

So looking at systemd.mount I see:

https://www.freedesktop.org/software/systemd/man/latest/systemd.mount.html#Options

This resource doesn't smell strongly of that... Should it? Did I miss something?

I think the approach of writing out a few more pseudo-code examples of how we'd use this would be beneficial...

[ffrank]

We can expose the additional options as resource parameters. In fstab they will be represented as "x-systemd" pseudo-options. The current proposed patch does not do this.

Reading about the special fstab options, I notice that the systemd-fstab-generator offers some additional options like x-systemd.makefs that make it very easy to spawn additional helper units that do convenient things. This seems to make fstab more worthwhile. (I don't see us building the same functionality into mgmt on the resource level. It should be feasible to create an mcl package that handles all that.)

[ffrank]

You mentioned in Matrix that you see a need to have a mount:systemd variant.

I can see it, but it would be nice to have your line of thought documented here.

[frebib]

My general perspective is that the mount resource should concern itself with only mounting filesystems and that configuration files such as .mount units and etc/fstab be handled either separately or at least secondarily.
Relying on systemd for actual mounting seems like a backwards approach because mounting is a feature of Linux/unix and not a feature of systemd.

[ffrank]

Ah but then most systemd resources are essentially wrappers for low level system functionality. A service is just a glorified process or two in the end 😅
Mounting via systemd should allow us to watch for events without polling (although I have not looked into this extensively), and is more in keeping with our general approach to interacting with the OS.

If we want to have a mount resource that does not concern itself with fstab nor unit files, we could indeed teach SvcRes to do that. On the other hand, we could have a very simple MountRes that wraps SvcRes like in the proposed patch (and avoid adding cruft to the interface of SvcRes), and this in turn could be wrapped by variants that add fstab or systemd unit backing.