8000 consider providing (templates for) best practice container spec? · Issue #867 · containerd/containerd · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

consider providing (templates for) best practice container spec? #867

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

Closed
ijc opened this issue May 16, 2017 · 2 comments
Closed

consider providing (templates for) best practice container spec? #867

ijc opened this issue May 16, 2017 · 2 comments

Comments

@ijc
Copy link
Contributor
ijc commented May 16, 2017

In moby/swarmkit#1965 I ended up copying chunks of github.com/docker/docker/oci/DefaultSpec into my containerd executor for swarmkit, which makes me a touch uncomfortable.

I wonder if perhaps there is scope for pulling out the common (i.e. obvious/non-opinionated) bits out of that code into some central location, such as a containerd package, where it can be used as a base?

Or perhaps this is more of a https://github.com/opencontainers/runc thing? Although I expect the further down the stack we go the less common ground there will be.

/cc @stevvooe

@crosbymichael
Copy link
Member

I think it is something that we can pull out into our client libs that will give a good default spec. Docker has good defaults that have worked for the majority of use cases and is secure so we should use that as our base. It should not go to OCI.

@ijc
Copy link
Contributor Author
ijc commented Jun 8, 2017

I think this is covered more than adequately by spec_unix.go:createDefaultSpec() now. I'll close.

@ijc ijc closed this as completed Jun 8, 2017
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

No branches or pull requests

2 participants
0