We need to define, which pod properties we initially want to support and how we want to map those to our systemd unit files.
I'll just start with my initial ideas in this ticket, if we find out that it becomes too unwieldy we'll move the discussion somewhere else.
Once we are agreed, I'll pull the result out into an ADR.
The following shows fields I've looked at so far and where in the systemd file I'd extract them, but I am sure that list is far from complete.
pod:
metadata:
name: -> name
spec:
containers: <we currently only allow one container per pod>
image: <used by virtual kubelet for downloading package>
env: Environment=...
command: ExecStart
args: ExecStart
name: <unused, taken from meta.name>
volumeMounts: <used by virtual kubelet to set up machine>
workingDir: WorkingDirectory
initcontainers: <we could either implement these as extra services linked by a before= statement, or build ExecStartPre commands from them, not sure which makes more sense>
restartPolicy: Restart
terminationGracePeriodSeconds: TimeoutStopSec <Systemd also offers TimeoutStartSeconds but I could not find a matching pod field, should we reuse this one for both?>
A few assumptions in there that might be worth discussing. We currently restrict pods to only have one container as the idea was to just create multiple pods if you need more. Do we want to change that and allow multiple containers? What would be the benefit - downsides?
For init containers, I am unsure how to treat these, I don't think it is relevant at this stage, but might be worth having a quick look at just to make sure we don't burn any bridges. There's two options, we can implement these as one-shot services that are required before our main service starts. That way systemd should run them once, before trying to start our main service (need to investigate the full implications of this).
Alternatively we can create ExecStartPre commands from these fields, which systemd would run once, before starting the main service.
Both have things pro and con I guess.. does anyone have any preference of the top of their heads?
Also, we should probably at least take the user to run this as from the PodSecurityContext, but that opens up an entire can of worms that I am not sure we are ready to deal with just yet.. thoughts?