generate: sync with runc's default spec

[cyphar]

Our default spec had a lot of bugs in it (it didn't include a cgroup mount, had too many capabiltiies, didn't mask paths that made sense to mask, etc). Just sync with what runc does (aside from setting terminal=false) so that users of generate get a much more sane spec file.

Signed-off-by: Aleksa Sarai [email protected]

[wking]

On Thu, Sep 14, 2017 at 02:41:48PM -0700, Aleksa Sarai wrote:

Just sync with what runc does (aside from setting terminal=false) so that users of generate get a much more sane spec file.

This is basically the opposite approach to the in-flight #379. We should pick a direction to go, or add an option so you can pick from a set of canned seed templates, including both your platform's minimal template and runC's template.

[cyphar]

@wking I'm currently very close to dropping my dependency on runtime-tools from umoci because this decision has just caused a few bugs on my side that wouldn't have happened if I'd just done it from within umoci.

[wking]

On Thu, Sep 14, 2017 at 11:07:52PM +0000, Aleksa Sarai wrote:

@wking I'm currently very close to dropping my dependency on runtime-tools from umoci because this decision has just caused a few bugs on my side that wouldn't have happened if I'd just done it from within umoci.

If you want a fuller stock config, and the runtime-tools maintainers end up going with #379 only, you'll need to either code your template in umoci or depend on runc for generation. If they decide to go this way instead of (or in addition to) #379, then you'll be able to use runtime-tools for generation.

I don't think anyone's arguing for keeping buggy configs in runtime-tools; it's just that runtime-tools has a ~57 issue/PR backlog, and a number of strategic decisions (like “what kind of config(s) do we want to supply out of the box?”) that it's been punting on for a while. I expect folks will pick a direction eventually (maybe today, who knows?), but if you don't want to wait, then (again) I don't think anyone has a problem with you carrying your own template in umoci…

[cyphar]

@wking I don't like rewriting stuff that already exists, which is why I used runtime-tools/generate (even though I've had to deal with lots of bugs as a result). But the value of runtime-tools/generate is massively reduced if I have to effectively define the template manually as a user (because the default is not going to be usable at all if we go with #379).

[wking]

...because the default is not going to be usable at all if we go with #379...

Obviously if there is one fairly consistent "usable" config, we should go with that. If there are a few target audiences we can bake in a few named templates to cover them. In the absence of a clear target audience, a minimal template is safe and easy. But I don't have a clear enough picture of a "standard user" to be able to say whether they want a read only root or not, etc. Maybe the runtime-tools maintainers do.

[mrunalp]

I would prefer having a more useful config and a template for a minimal template as something that we can provide.

[zhouhao3]

When I was looking at the goal of v0.6.0 in ROADMAP, I discovered that the generation of the default json file was the last remaining problem. Since #194 has already been merged, we need to discuss whether it is still necessary to streamline the generated json file. I think we might need add a new option to generate a normal version of json (the default) or generate a streamlined json file (like this or #379). @cyphar @wking @liangchenye @mrunalp WDYT?

[wking]

I think we might need add a new option to generate a normal version of json (the default) or generate a streamlined json file (like this or #379).

If the maintainers feel like there's a clear "standard user", then I don't have a problem with them picking values that work for that user. Personally, I don't have that clear understanding. If we go with the named template approach, we could support minimal, docker, runc, etc. pretty easily, then we don't need to agree on one best default, and we can offload picking the default values to external maintainers (runtime-spec for minimal, Moby for docker, runc for runc, etc.). But since it's easy for callers to provide their own template, I don't have a strong opinion on how to handle these stock templates.

[zhouhao3]

If the maintainers feel like there's a clear "standard user", then I don't have a problem with them picking values that work for that user ...

I do not think there is any special need at present. I can put it aside and wait until the release of the official version, or when there are specific needs.