make config and metadata visible #22
Conversation
The molecule config contains the OCI path and tag, which is important if we want to track what container image is mounted at a particular path, and thus what container might need to stop if a verity error is detected in one of the atoms in the molecule it's using. This commit writes that config to a JSON file in the metadata path. Signed-off-by: Michael McCracken <[email protected]>
|
|
Otherwise looks fine to me, thanks |
In order to make it trivial to read the config.json for a given mount, move the metadata path to /run/atomfs/meta/$munged-mountpt-name/ Signed-off-by: Michael McCracken <[email protected]>
mikemccracken
force-pushed
the
2024.09.30/main/make-meta-visible
branch
from
91e6e84 to
98626ba
Compare
|
derp! thanks, fixed |
|
thanks for the review, I was wondering if there was a reason to object to moving away from the nice neat tucked-under-the-mountpoint approach. I didn't look too hard but didn't think of a nice way to get at the meta of a still-mounted molecule with the previous scheme.. |
|
Well, now that you mention it, there is reason :) If different users (or different root logins) each try to mount to the same mountpoint in different namespaces, which is perfectly legitimate, then there will now be conflicts, right? |
|
that's a good point, do you have a scheme in mind that fixes that? Is there a way to get a unique string that maps to a given mount namespace? Or alternately maybe we should keep the old behavior as default and add a |
|
Yeah, you should be able to use: For the mounter. That mntns name will be unique as long as that mntns exists, so if it created the mount, it'll live as long as the mount does. |
|
closing this for a new PR with this change but also more. My earlier assertion that "Other programs using atomfs as a package are free to set the metadata path however they want, if they need it to be accessible while the molecule is mounted." may have been true but it meant duplicating a lot of atomfs code in those programs, so my new PR has a different approach where the mount code moves into the atomfs package and everything using it to mount a molecule will get the metadata at |
"write molecule config to metadata path" is important to be able to trace an event that points at a failed DM Verity volume, through its molecule mountpoint, to an OCI image and potentially to a container running that image that we then need to stop.
"move metadata path to /run" is handy for testing, but is not strictly required, since it only changes the behavior of the
atomfsbinary. Other programs using atomfs as a package are free to set the metadata path however they want, if they need it to be accessible while the molecule is mounted.Fixes #21