-
Notifications
You must be signed in to change notification settings - Fork 66
use upper directory of former 'rw' session in 'ro' mode #674
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use upper directory of former 'rw' session in 'ro' mode #674
Conversation
|
Instance
|
|
Instance
|
| # the ${RESUME} directory or tarball | ||
| # to be able to see the contents of the read-write session we have to mount | ||
| # the fuse-overlayfs (in read-only mode) on top of the CernVM-FS repository | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we print something to stdout here to notify that we have detected an overlay directory from a previous build, and are mounting it read-only? I think that will help with future debugging if we ever have issues.
| EESSI_FUSE_MOUNTS+=("--fusemount" "${EESSI_READONLY_OVERLAY}") | ||
| export EESSI_FUSE_MOUNTS | ||
| else | ||
| # basic "ro" access that doesn't require any fuseoverlay-fs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe also add an explicit echo here, just so we easily see in which branch we went.
casparvl
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once the two explicit echo's are added to make it more transparent into which branch we went, I'd say this is good to go.
#676 (comment) proves that this enables the test step of running in ro mode with the previous overlay-upper mounted as lowerdir (i.e. read-only). It shows that the patchelf we just built in the build step is available in the test step. At the same time, #677 proves that without this PR (#674 ), the patchelf we just built in the build step is not available in the test step.
In summary: this PR does exactly what it says on the label :)
This PR is essentially redoing #550. Original description below. It is also doing a little code polishing replacing TAB with spaces.
Use case for this is that we want to test software additions to a CernVM-FS repository. Typically we would first run
eessi_container.shwith--access rwto make the repository writable with an overlayfs. The changes are stored in someoverlay-upperdirectory (under some/tmpdir or in a tarball of that/tmpdirectory). When we want to test the additions later we can runeessi_container.shwith--resume TMPDIR_OR_TMPTARBALL. However, until now this only worked when using--access rwwhich would make the repository again writable, which is likely not what is wanted in a test (because in actual use/cvmfs/*mounts are read-only). In fact, thetest-suite.shrun after a build job has finished, uses--access ro(read-only), but this access mode did not recognise changes in anoverlay-upperdirectory.This PR merges an existing
overlay-upper(given via--resume ...) on top of a CernVM-FS repository. Because it only uses thelowerdiroption offuse-overlayfsthe merged directory is mounted read-only.Because the mounting of directories under
/cvmfsis done late in theeessi_container.shscript, this should also work with the changes introduced in #618, e.g., one should be able to run something likewhich reports about a temporary location used such as
/tmp/eessi.abc123defgand then