[all2]

What I think I'm reading here is that the abstraction is misplaced.

How then would one leverage 9p filesystems to solve the containerization problem?

I've had vague intuitions that Plan9 would have elegantly solved some of our problems that Docker, Terraform, Kubernetes, etc. were all created to be solutions for. But I'm unsure as to the proper shape of the solution.

[smasher164]

> How then would one leverage 9p filesystems to solve the containerization problem?

In Plan 9, processes are sandboxed by default, so they only see what is exposed to them. You utilize mounts to attach filesystems to processes, and since all APIs are done through the filesystem, you can trivially wrap/extend/replace those APIs with different implementations.

Essentially, everything-is-a-filesystem + 9p gave you a kind of capability-based security.

[butterisgood]

The sandboxing is pretty important to keeping things isolated, but I've also wondered about the right way to ensure my writes to files are "atomic" in 9p, and never really understood the guarantees or lack thereof.

In POSIX-land, I can write to a temp file, sync it and the parent directory, and rename it over the original and be pretty well guaranteed anyone accessing the file by name will never see a partially written to file.

How the heck does this work in 9p servers? For a "synthetic" file server one could decide to update the state depending on receiving full payloads I presume, and discard anything that's nonsense or incomplete. (like changing the baud on a serial port through the control file - you need to know the format of the commands and send the correct payload)

But what does one do about regular files? Write to temporary files and rename over them? Do the Plan 9 file systems have any atomic guarantees (HJFS, Fossil, KenFS etc?) and do I need to understand each of them?

[rektide]

I reallyike both csande17 and smasher164's comments about capabilities.

You question I admit left me a little stuck. Seeing their answers provided some clues.

I think there's a bit of a distinction, that Docker, Terraform, Kubernetes tend more to be for a simpler part of orchestration: summoning resources.

Rather than figuring out what to beget, plan9's universe was more about figuring out what context to spawn resources (effectively their own chroots with some volumes) in. I think that is more the clear lesson here.

There's semi orthogonal concerns. So many of modern tools help us spawn resources, but figuring out what capabilities/affordances to expose to them is actually quite a bit back from where we've already tread.

It turns out exposing state as a filesystem, then mounting subtree of state as volumes in other apps is a quite composable powerful general purpose paradigm, frankly surpassing what we are up to now. And we already have some very nift weird volume mount stuff going on in kube, but it's still not this comprehensively useful: apps just don't make a practice of exposing their state in the universal way (as a filesystem) as the 9p practice did.

[csande17]

The version of this idea that I've heard is that, in the idealized Plan9 "everything is a file" universe, the only containerization primitive you need the kernel to provide is chroot. Then you can implement things like network namespaces entirely in userspace, as filesystems that get mounted at the appropriate location in the container.

[e12e]

> How then would one leverage 9p filesystems to solve the containerization problem?

Well, there's:

https://wiki.qemu.org/Documentation/9psetup

Then again, there's also an alternative citing overhead with 9p being a network protocol:

https://virtio-fs.gitlab.io/