Follow runc usage of libcontainer about agent

[sboeuf]

@laijs well you mentioned the reason why we don't have the pid. That's because we are providing the shim's pid, and this is the runtime responsibility. We're trying to implement properly what runc has to offer, but I don't see why we should try to make the gRPC API reflecting runc API.
The CreateContainer() does not start the container process, and for this reason, we cannot provide a PID in response of this. And there is no reason to try to provide the shim PID through this API, those are different things. The guest PIDs from inside the VM should not be mixed up with the host PID of the shim, this would bring more confusion IMO.

[laijs]

@sameo @sboeuf @bergwolf

[laijs]

but runtime exec is allowed before runtime start, how do you achieve this? @sboeuf

[sboeuf]

@laijs is it ? This is very weird since you should not be able to exec a process if the container process itself is not running, right ?
Now, let's say it is acceptable (I really think it's not but anyway), we can still do it by calling into exec after create, we don't need the PID of the container for that, we only need the container ID.
@laijs am I missing something here ? I ask because I am trying to understand what you're trying to achieve with this.

[laijs]

runc allows this behavior.
We'd better to follow the way that runc calls into libcontainer, unless there is a strong demand with convictive reasons.

[laijs]

@sameo @sboeuf The shim should be created after runtime create returns before runtime start
In this case, the shim will be started without NewProcessResponse, so a special tunnel has to be set up to tell the shim about it. It complicates everything.

CreateContainer() returning NewProcessResponse or runtime generating process ID can solve this problem.

[sboeuf]

@laijs I am sorry but I am gonna repeat myself on this one, why do you need the ID from the agent for this case ?
The shim will be started by runtime create and you will have the real PID in your hand so that you can fill the pid file properly. Why is that not enough ?

[laijs]

The shim will be started by runtime create and you will have the real PID in your hand so that you can fill the pid file properly. Why is that not enough ?

But the shim doesn't have the pid of the process inside the vm. so the shim can't issue any API to the agent. Unless we add some much APIs for it, or the shim has to listen on a socket and wait for the runtime start telling him. I am sorry I didn't add enough detail.

[sboeuf]

@laijs Ah thanks for those details, now I understand it :)

So I agree returning the ID could be an option, but the thing is that we don't have the PID at that moment (I know there is a discussion about having this generated from the agent so we could generate that from any function of the agent).

Another one option would be to consider that a shim started with no process ID (or process ID == 0) means this is the container process and in that case, it would actually provide a PID of 0 or 1 along with the container ID, so that the agent would know what process it should tie to the request.

@sameo @WeiZhang555 WDYT ?

[bergwolf]

I updated the issue title to better match current description in the first comment