Add job containers package

[dcantah]

• Add JobContainer and JobProcess types as the two types to represent a job container
  and a process in a job container.
• Add logic to find the executable being asked to run for a job container.
• Logic to launch the container as specific user.
• Logic to mount the containers scratch space on the host to a directory.

Signed-off-by: Daniel Canter dcanter@microsoft.com

[kevpar]

How does this integrate into the shim? Are things like the pod/task/exec types for job containers coming in a future PR?

[dcantah]

@kevpar Yep right after this. The HCS exec/task types are re-used is how I have it now. If the annotation is set (or one can imagine if the OCI spec field is set later on) we just do jobcontainer.Create instead of hcsoci.CreateContainer. JobContainer implements cow.Container so you can just pass it along as is to all of the task/exec types.

[kevpar]

@kevpar Yep right after this. The HCS exec/task types are re-used is how I have it now. If the annotation is set (or one can imagine if the OCI spec field is set later on) we just do jobcontainer.Create instead of hcsoci.CreateContainer. JobContainer implements cow.Container so you can just pass it along as is to all of the task/exec types.

IMO we should have that PR out as soon as it is ready, given the short timeline we have to get this feature in. Worst case some of the interface for calling into the job containers package would have to change, which doesn't seem like a big deal.

[dcantah]

IMO we should have that PR out as soon as it is ready, given the short timeline we have to get this feature in. Worst case some of the interface for calling into the job containers package would have to change, which doesn't seem like a big deal.

It's ready, it just uses work in this PR. I can add just the commit with the shim work to a branch and PR that and rebase on this when it gets in

[kevpar]

IMO we should have that PR out as soon as it is ready, given the short timeline we have to get this feature in. Worst case some of the interface for calling into the job containers package would have to change, which doesn't seem like a big deal.

It's ready, it just uses work in this PR. I can add just the commit with the shim work to a branch and PR that and rebase on this when it gets in

I don't think we need to block to get that PR out is my point :) If this PR is b1 -> master then you should be able to publish another PR that is b2 -> b1 and I think it will work properly.

[dcantah]

IMO we should have that PR out as soon as it is ready, given the short timeline we have to get this feature in. Worst case some of the interface for calling into the job containers package would have to change, which doesn't seem like a big deal.

It's ready, it just uses work in this PR. I can add just the commit with the shim work to a branch and PR that and rebase on this when it gets in

I don't think we need to block to get that PR out is my point :) If this PR is b1 -> master then you should be able to publish another PR that is b2 -> b1 and I think it will work properly.

I thought this one wasn't far off is why but that didn't turn out as planned 😆, I'll push the shim PR.

[dcantah]

@kevpar Didn't come to mind but as the branch is on my fork it's not as easy as that actually. I opened a PR against my fork dcantah#1 if we want to review it here and merge into this branch

[kevpar]

LGTM