An sysop runs a powerful box running Serpent OS natively, that users alan, bea, charlie, doris, eric and freya have access to. They use it to create and test moss containers.
Each user has a $HOME and therefore an $XDG_CACHE_HOME dir (where moss stores .stones etc.)
They use the userns capabilities of boulder-rs (and implicitly then moss-rs from within boulder) to stand up individual testing environments (possibly for long-running tests/benchmarks/whatever that they don't want to run on their anemic ultraportable laptops when they sit down at the coffee shop).
The sysop has a recurring job that runs (as root) sudo moss sync --onlyfetch every hour or so. The newly fetched stones aren't sync'd to the system specification unless they are known to be in a sane state; when they are sync'd, the sysop does a sudo moss sync --nofetch.
This functionality would ensure that any new userns containers using system-available .stones don't download those exact same stones to seven different $XDG_HOME_CACHE dirs; instead, most .stones from upstream repos are stored in system-managed moss download cache.
It is, however, unavoidable that users will use their own copies of the exploded assets (unless we have an actual de-duplicating FS underneath it all)
As a corollary to the above use case, we might need to figure out a way for user moss sync operations to wait on in-progress system sync operations? This could be via a moss-rs system daemon, where the daemon knows about the operations that are in progress in terms of the moss system store?
It might also be useful if all boulder instances could somehow share an asset (tar.gz/tar.zst) download cache via overlays?
Use Case
An sysop runs a powerful box running Serpent OS natively, that users alan, bea, charlie, doris, eric and freya have access to. They use it to create and test moss containers.
The sysop has a recurring job that runs (as root)
sudo moss sync --onlyfetchevery hour or so. The newly fetched stones aren't sync'd to the system specification unless they are known to be in a sane state; when they are sync'd, the sysop does asudo moss sync --nofetch.This functionality would ensure that any new userns containers using system-available .stones don't download those exact same stones to seven different
$XDG_HOME_CACHEdirs; instead, most .stones from upstream repos are stored in system-managed moss download cache.It is, however, unavoidable that users will use their own copies of the exploded assets (unless we have an actual de-duplicating FS underneath it all)
As a corollary to the above use case, we might need to figure out a way for user
moss syncoperations to wait on in-progress system sync operations? This could be via a moss-rs system daemon, where the daemon knows about the operations that are in progress in terms of the moss system store?It might also be useful if all boulder instances could somehow share an asset (tar.gz/tar.zst) download cache via overlays?