Juju forbids storage API to have nested mounts

[Pedro Guimarães]

Juju forbids to have nested mount points, e.g.:

volume 1: /var/lib/myjujuvolumepath1

volume 2: /var/lib/myjujuvolumepath1/asubfolder

This will fail in the check [1].

However, this setup would allow us to have more careful storage separations in our charms.

[1] https://github.com/juju/juju/blob/1c4005149780c7d359c9b3a38c4b0371f9eeb1ed/state/filesystem.go#L1476-L1481

[John A Meinel (jameinel)]

I think it is true that we forbid it. I'm not 100% sure that we would have to (we'd have to be careful about ordering and when we're doing the mkdir), and it gets far more complex if we have multiple applications on the same machine that also end up trying to go on top of each other.

However, its also a little unclear as to why you actually need to have nested, vs just sibling directories.
In general, the actual recommendation is to avoid forcing a `location` at all and configure the application to use the directory that juju supplies rather than having juju place the storage where the application needs. (most applications have that configuration, and it scales much better if you have multiple applications)

[Pedro Guimarães (pguimaraes)]

Hi @jameinel, answering your questions in parts:

> However, its also a little unclear as to why you actually need to have nested, vs just sibling directories.

So, our use case is simple: we want to preserve the /var/snap/opensearch/common folder. That folder contains all the core information for the app, including all user data. Therefore, we deploy it in a separate volume.

However, within the /var/snap/opensearch/common, we also have /var/snap/opensearch/common/var/log/, which receives the logs.

We want to isolate the IOPS to logs from the IOPS to data; as well as enclose the logs to not outgrow our own data.

Therefore, we need a 2nd volume within the snap folder. That is actually a normal use case in CIS, where we may have:
/var/log -> one partition
/var/log/audit -> another partition

That is actually mandated for CIS lvl. 2

> In general, the actual recommendation is to avoid forcing a `location` at all and configure the application to use the directory that juju supplies rather than having juju place the storage where the application needs. (most applications have that configuration, and it scales much better if you have multiple applications)

Snaps have a particular folder structure. We must be able to say where folders go and they must land under /var/snap/<app>/{common,current}.

We do not have a choice there.