timthelion
commented
9 years ago Here is my current plan, in part to break up subuser to make it less monolithic, and in part to move away from Docker which is also too monolithic.
There should be a triad of utilities:
subuser-run
subuser-run should take a permissions.json file and a path to a mounted root file system and do subuser's running magic. The difficult part in breaking out subuser-run into it's own utility is as follows
- Currently,
subuser-runfinds out where to mount the subuser's home directory by looking at the user wide subuser config. - Currently subuser run launches the xpra bridge, which happens to consist of subusers. This service architecture needs to be expanded in the future, to also include an at-spi bridge so that vision impaired people can use subuser as well. So the ability to look up other subuser's is unfortunately a must.
- I would like
subuser-runto be a suid binary (the only one involved). This would allow subuser to be run by normal users. This means thatsubuser-runwill have to do the actual COW mounting of the root file systems itself.
The subuser registry
This provides support for atomic updates, update loging, rollbacks, locking and image management. This is the main part of the subuser source code now.
The subuser storage backends
These provide support for:
- Mounting root file systems for containers in a COW manner, so that they can be used by
subuser-run. - Saving root file systems in storage backends.
- Transfering root file systems(images) over the network.
- Providing a hash based method for refering to root file systems.
I have been discussing with Eric Myhre of the repeatr project on working on the storage backends in joint. This utility will likely be maintained outside of the subuser project by him.
Subuser currently has a dependency resolver and build system. This is currently integrated with the subuser standard. The system is good, but the integration with subuser is not sufficiently unix for my taste.
Tear it out!