-
Notifications
You must be signed in to change notification settings - Fork 554
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
Host system bundles #332
Comments
this topic has come up. Even then, the |
I believe a rootfs should still be supplied for these host system bundles - it is just that the host supplies it and not the bundle. Make sense? The goal is for many containers to share the same rootfs at runtime, but not to share the hosts FS directly. |
On Mon, Mar 07, 2016 at 07:05:34AM -0800, Vincent Batts wrote:
Linking into past discussions, see [1,2].
|
Thanks for the refs. I shall read them today. Any chance you can summarise them here? |
On Mon, Mar 07, 2016 at 01:38:47PM -0800, Christopher Hunt wrote:
I think discussions like this are supposed to happen on the list 1,
|
Apologies. I shall continue the discussion on the list. The OCI website didn't make it obvious that there was a list hence my raising of the issue here. |
On Mon, Mar 07, 2016 at 03:36:40PM -0800, Christopher Hunt wrote:
No need to apologize, especially to me since I'm not a maintainer ;). |
In addition to file system bundles, does the spec deem it permissible to ship only a
config.json
and have theroot.path
assume that it will be "provided". I'm thinking of usingconfig.json
in a way that it can assume a rootfs being provided by the host OS. My goal is so that I can control the underlying file system of all containers, which will then facilitate patching in the case of security vulnerabilities.Could such a scenario be introduced as a "host system bundle" perhaps? I'd be happy to contribute the beginnings of its spec if it were deemed as being useful.
Thoughts?
The text was updated successfully, but these errors were encountered: