add support for `command` field in `container` components

[kadel]

devfile/registry#102 (comment)

Odo is not able to use devfiles that have container component with a custom command. Problem is that in the current odo implementation it overrides the default process in deployment which means that supervisord is not started. When supervisord is not running, odo is not able to execute any commands in the container.

A quick fix is for odo to ignore command and args fields in container components.
This has been done in #5620

The proper fix is going to be to keep using supervisord as pid1, and execute the commmand with args "on the side" as a separate process.

/kind bug
/priority high

[rm3l]

I'm summarizing my notes below after looking into this issue:

The approach suggested here to run the user-defined command and args on the side as a separate process would be ok if they were both mandatory in the Devfile spec, I think.

As command and args are optional in the Devfile spec, there might be cases where an args could be defined without a command and vice-versa, in which case (as mentioned in devfile/api#679 and in the spec) we should use whatever is defined in the container image. I guess this is because containers might generally need to do some work on startup and overriding the entrypoint would probably break that.
So it might be complicated for odo to determine in advance what should be the command-line of that main process without starting the container.

As discussed, I investigated and did some preliminary research/testing to see if we could instead run our supervisord process in the container and attach it as a child of the container main one, and unfortunately, it looks like there is no way to change the ppid of a given process outside of the kernel. Even if it was possible to do so, I am not sure about signal handling from the parent to its children here. Also, in case the container restarts (for any reason due to the ephemeral nature of a pod), I think we would lose the supervisord process.

---

I was thinking about an alternative approach that builds upon the fact that, to me, Kubernetes Pods were precisely designed to solve this issue of having multiple cooperating processes (as containers) that form a cohesive unit of service. We could run multiple containers in the same pod, sharing a same network namespace and volumes; they could even share the process namespace.

So with that in mind, the Deployment and Pod specification generated by odo could be made up of multiple containers :

1. the main container that would just meet the Devfile spec, by using either the command and args defined in the Devfile or whatever is defined in the image. It does not matter if the main container runs a terminating process, because the sidecar container(s) below would still be running and non-terminating. So port-forwarding would still work, I think.
2. in the same pod, odo could inject additional sidecar container(s) that would share the projects volume, plus other environment variables defined in the main container:

• firstly, we could inject only one sidecar container running our supervisord process and running either the devrun or debugrun processes, just like it currently behaves: https://github.com/redhat-developer/odo-init-image/blob/master/devfile-supervisor.conf
• later, if we want to get rid of supervisord (and the init container), odo could directly inject a sidecar container running either the devrun or debugrun process.

I am not sure yet to what extent this would solve the issue here (because I may probably be missing some pieces).

@kadel @feloy Any thoughts?

[feloy]

Note that it could also be possible to share the Process (Pid) namespace between containers of a same pod:
https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/

[feloy]

As discussed with @rm3l , I suggest to get rid of supervisord, and take advantage of the fact that odo dev is now a long running command (as opposed to odo push), and we could start the run command from odo without releasing it (with the help of some go routine).
We could pass the cmd and args as is to the Deployment's container

[kadel]

As discussed with @rm3l , I suggest to get rid of supervisord, and take advantage of the fact that odo dev is now a long running command (as opposed to odo push), and we could start the run command from odo without releasing it (with the help of some go routine).
We could pass the cmd and args as is to the Deployment's container

This is a good idea 👍 It looks like a nice and clean solution.

The only downside that I can see here is that the odo dev command will always have to stay as "long running" command once we do this. But that might be actually ok as we are already relaying on this with port-forwarding.

Let's try to implement this approach. This could drastically simplify odo code.

[rm3l]

+1 for this approach. Thank you all for your feedback.