Extend template to accept namespace (pid)

[gianarb]

Hello

This morning I had some fun with @thebsdbox pairing on writing action to kexec inside a new shiny operating system.

The outcome is this action tinkerbell/actions#8 . It almost works. What is missed is the ability to attach the PID namespace of the host to the action itself.

We even streamed out work on Twitch and as you can see at the end of the video we validated that running the action locally with docker run --pid=host made the trick and kexec successfully.

So we are almost there but we need to extend the template in a way that will allow passing the pid namespace.

There are at least two possible solutions.

So we can add the field action.pid=string to Template in this way we can pass that value to the Docker API.

PRO: It is simple
BUT I prefer to go a little bit deeper and see what the OCI has to offer because ideally, I would like to be able to replace Docker with other things in the future and I am wondering pid=<string> will make it harder. If OCI sounds too low level at least having a look at contained...

[thebsdbox]

Looking at the spec, we can later map the pid= to either a named namespace or check if it's an int and map to the namespace ID. https://github.com/opencontainers/runtime-spec/blob/master/config-linux.md#namespaces

I'm in favour of the simple option, it matches the underlying runtime Docker .. which matches its underlying runtime containerd.

[gianarb]

@thebsdbox yep, I know that docker relays on what containerd can do that relays on what runc can do, the question is how much it is hidden in those layers and what do we want to support?

--pid=""  : Set the PID (Process) Namespace mode for the container,
             'container:<name|id>': joins another container's PID namespace
             'host': use the host's PID namespace inside the container

Do we want to act as a proxy and accept all the possible parameters? How it will be even possible or useful to use pid: container:name? Do we want to share PID namespace between actions (so mapping container:name with action:name) maybe?

I know @jacobweinstock has an idea and @markyjackson-taulia will come up with a possible implementation. I personally don't have an idea about how it should be implemented but I would like to a clear and hard to get wrong feature.

[jacobweinstock]

I lean toward using something like pid: host or hostPid: true for now, as we know the use cases (kexec, reboot) we need it for, and then revisit accepting others in the future when other use cases arise.

I think there are a few schools of thought here found in other projects.
docker: see Gianluca's comment above
linuxkit yaml: pid sets the pid namespace, either to a path, or if host is specified it will use the host namespace.
kubernetes pod spec: hostPID: true - Use the host's pid namespace. Optional: Default to false.
kubernetes sharing pid namespace between containers in a pod: shareProcessNamespace: true
containerd: uses the OCI spec which Dan commented on above

[thebsdbox]

I lean toward using something like pid: host

+1

[gianarb]

I lean toward using something like pid: host

@thebsdbox @jacobweinstock I think with pid: string you are suggesting an enum? Or just an empty string? What other value should it get when it is not host? Can you elaborate on it as a feature and not only as an attempt at making kexec work? We are the PM here, so let's try to help each other :)

At least hostPid: true is clear and harder to misuse 👍

[thebsdbox]

This is a bit of a blocker on new actions we're wanting to write, has there been the opportunity to write anything so far?

[markjacksonfishing]

@thebsdbox I am starting this wrk today

[thebsdbox]

Awesome, I did a PoC today so I could carry on playing -> https://github.com/thebsdbox/tink/tree/pid feel free to pull anything from there that makes sense. I've never used protos before so I had to kinda make it up as I was going along 😬 I also missed the db bit so all the bits looked like they should work but the pid stuff didn't exist inside the tink-worker 🙄

[thebsdbox]

This can be closed with #436