generate: sync with runc's default spec #477
Conversation
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 <asarai@suse.de>
|
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.
|
|
@wking I'm currently very close to dropping my dependency on |
|
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…
|
|
@wking I don't like rewriting stuff that already exists, which is why I used |
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. |
|
I would prefer having a more useful config and a template for a minimal template as something that we can provide. |
|
When I was looking at the goal of |
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 |
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. |
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 asarai@suse.de