Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

generate: sync with runc's default spec #477

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

cyphar
Copy link
Member

@cyphar cyphar commented Sep 14, 2017

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]

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
Copy link
Contributor

wking commented Sep 14, 2017 via email

@cyphar
Copy link
Member Author

cyphar commented Sep 14, 2017

@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
Copy link
Contributor

wking commented Sep 14, 2017 via email

@cyphar
Copy link
Member Author

cyphar commented Sep 14, 2017

@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
Copy link
Contributor

wking commented Sep 15, 2017

...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.

@Mashimiao Mashimiao added this to the v0.6.0 milestone Sep 26, 2017
@mrunalp
Copy link
Contributor

mrunalp commented Sep 28, 2017

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

@zhouhao3
Copy link

zhouhao3 commented May 11, 2018

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
Copy link
Contributor

wking commented May 11, 2018

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
Copy link

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.

@zhouhao3 zhouhao3 modified the milestones: v0.6.0, v1.0 May 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants