config: Make 'process.args' optional

[wking]

Since be59415 (Split create and start, 2016-04-01, #384), it's possible for a container process to never execute user-specified code (e.g. you can call ‘create’, ‘kill’, ‘delete’ without calling ‘start’). For folks who expect to do that, there’s no reason to defineprocess.args.

The only other process property required for all platforms is cwd, but the runtime's idler code isn't specified in sufficient detail for the configuration author to have an opinion about what its working directory should be.

On Linux and Solaris, uid and gid are also required. My preferred approach here is to make those optional and use platform defaults:

If unset, the runtime will not attempt to manipulate the user ID (e.g. not calling setuid(2) or similar).

But the maintainer consensus is that they want those to be explicitly required properties. With the current spec, one option could be to make process optional (with the idler's working directory unspecified) for OSes besides Linux and Solaris, but the main reason that Windows doesn't have a user property is that we don't know how to specify it. I expect all platforms will have some sort of required user field, which means they'll all have to define process.

While I'm indenting the sub-properties, also wrap them to one line per sentence.

There was also some related discussion in opencontainers/runc#827, although I'm not clear on the intended policy after that discussion.

[wking]

I added a second commit that makes process.user required, since that was the reason I used above to make process required.

[crosbymichael]

NOTLGTM

I don't like the proposal but I can be swayed if other maintainers feel strongly for it.

[wking]

On Fri, Nov 04, 2016 at 3:37pm -0700, Michael Crosby wrote:

I don't like the proposal…

Are you rejecting the “it's possible for a container process to never execute user-specified code (e.g. you can call ‘create’, ‘kill’, ‘delete’ without calling ‘start’)” use case? Or do you accept that use case but feel they should insert a dummy process.args? Or do you accept the use case and the optional process.args but have some technical quibbles with this PR?

[mrunalp]

I am in favor of having the user specify the args. Even though the flow where the command is never executed is supported, that isn't a normal flow but more for scheduling or gc where one removes the container without ever starting the container after creating it.

[wking]

On Thu, Nov 10, 2016 at 11:25:48AM -0800, Mrunal Patel wrote:

I am in favor of having the user specify the args. Even though the
flow where the command is never executed is supported, that isn't a
normal flow…

So “specify dummy args” for those folks? The current:

The executable is the first element and MUST be available at the
given path inside of the rootfs.

language makes this:

{"process": {"args": ["/foo"], …}, …}

illegal, because /foo doesn't exist. If the user is just holding
mount namespace open, they may have an empty rootfs. I guess they
could use:

{"process": {"args": ["/"], …}, …}

That seems like a silly hoop to jump through (like using an empty
tarball layer 1).

The only benefit I see to keeping process.args required is to get
validation errors when folks forget to specify it. But it seems like
you could accomplish that same goal in validation, without making it a
strict requirement in the spec itself.

But required hoop-jumping is not the end of the world ;). If there
are two maintainers in favor with the status quo and none in favor of
an optional process.args, then one of you should probably close this.

[crosbymichael]

Well its hard to tell what really changed in this PR because you changed an entire block instead of what you were talking about in the description. There are more changes in this PR than just making args optional, therefore, I'm going to close it.

If you want to propose a single change that is easy for us to review and understand please open a new, small, and concise PR with only the change you are proposing and we can continue the discussion there for optional args. You are making the process hard on the maintainers and yourself by your current strategy. Multiple small, focused PRs are much better for everyone than big ones with unrelated changes.

[wking]

On Fri, Nov 11, 2016 at 05:23PM -0800, Michael Crosby wrote:

If you want to propose a single change that is easy for us to review and understand please open a new, small, and concise PR with only the change you are proposing and we can continue the discussion there for optional args.

Filed in #620.