17:02:30 #startmeeting 2015-10-07 discussion 17:02:30 Meeting started Wed Oct 7 17:02:30 2015 UTC. The chair is vbatts|work. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:30 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:02:30 The meeting name has been set to '2015_10_07_discussion' 17:02:59 philips will not be making it today. Sounds like his batteries are dead, somewhere in dublin. 17:03:09 okay 17:03:51 Good day 17:03:55 Howdy 17:03:57 hi 17:03:59 yo 17:04:02 hi 17:04:05 . 17:04:06 hello 17:04:11 aloha 17:04:20 #info RobDolinMS_ from Microsoft in Seattle 17:04:34 hi vbatts 17:05:06 o/ 17:05:18 Hello 17:05:30 #topic duglin clarifying a couple of things 17:05:49 #info duglin is Doug Davis from IBM 17:06:08 https://github.com/opencontainers/specs/pull/209 17:06:23 hello 17:08:59 https://github.com/opencontainers/specs/pull/210 17:09:04 Suggested replacing "Equinox" with "fiber hotel" and Doug fixed 17:09:38 (or will fix) 17:12:09 vbatts|work and mrunalp distinguishing between "filesystem bundles" and "on the wire bundles" for runtime.json 17:14:51 duglin points out that the bundle.md is just talking about filesystem bundles, and we're still not sure whether wire bundles are in or out of scope 17:15:33 solaris wouldn't be needing the runtime.json , so we prefer this be optional 17:16:02 Even for a running container on filesystem 17:16:43 yeah, I agree, it should be optional everywhere 17:16:46 Fair, it could be optional 17:17:54 anuthan is Abhijeeth Nuthan 17:18:09 crosbymichael asks where the runtime.json settings come from for Solaris 17:18:20 anuthan explains how Solaris handles this 17:18:22 anuthan says they're part of the runtime's configuration outside of the bundle 17:18:51 In config.json, there is a Linux object and a separate Solaris object 17:19:07 #action anuthan to mail the list with more details on how Solaris handles it 17:19:14 #action anuthan to send an mail elaborating on this 17:19:47 Doh; double-posted with wking :) 17:20:16 ;) 17:20:20 more actions :) 17:20:26 vishh: asks how hooks are handled 17:20:42 anuthan says Solaris doesn't currently support hooks 17:21:10 he feels like hooks should be handled by the runtime itself, but it's complicated ;). We'll wait for more details 17:22:57 should we amend #210 to make runtime.json optional? 17:23:23 mrunal thinks maybe, crosbymichael is concerned about leaving some config unspecified 17:23:46 I think we should land the #210 rewording as it stands and then have a separate discussion on the list about making runtime.json optional 17:25:42 vbatts|work thinks maybe the distinction is how much the bundle is asking for, vs. what the runtime is granting 17:26:35 anuthan configuration is set for the zone in which the container runs, so the zone config sets maximum caps on resources 17:27:14 anuthan we don't want to lose that runtime.json configuration when moving the container between hosts 17:28:53 Anyone else have trouble hearing Vish? 17:29:16 yeah, his audio stream goes a bit underwater 17:31:44 jlb13: maybe the config.json / runtime.json split makes sense, and the current Solaris stuff can be reshuffled to use both configs. 17:31:56 i think correct, yes 17:32:25 feel free to add your own language ;). I'm just trying to paraphrase for the minutes :p 17:32:48 duglin: why require runtime.json if we can guess reasonable defaults 17:32:56 e.g. with 'runc spec' 17:33:12 #info duglin asks: If through runc spec we can produce valid defaults, why require runtime.json to be present? 17:33:45 mrunalp: we don't specify defaults in the spec (the runC values are runC-specific) 17:33:47 #info We don't currently have default values in spec. 17:34:11 #info (said mrunalp) 17:34:40 duglin: maybe you should be able to say "I don't care", and have them use unspecified defaults (whatever the runtime wants to use as the defaults) 17:35:34 File can be required w/ some fields required and some fields optional. 17:35:53 lk4d4: Your voice is breaking up 17:36:33 lk4d4: doesn't like runtime-specific defaults 17:36:44 vishh: agrees, no runtime-specific defaults 17:36:57 vishh: clearly state which fields are optional and which are required 17:37:06 mrunalp: seems like bluejeans wants too much memory from my laptop 17:37:16 ^^ we're getting better at that now, but we still have more to do 17:37:21 duglin: require 17:37:33 ^ "a runtime.json" 17:37:58 duglin: is ok keeping it required for now, and revisit once we finish required/optional for the fields inside 17:38:00 One more thing is that the standard container tools should take care of validation and defaulting. 17:38:06 I agree with duglin 17:38:19 +1 to duglin 17:38:21 vishh: standart container tools like docker or like runc? :) 17:38:22 vishh: can you define "the standard container tools"? 17:38:27 For example, in the case of linux, OCI should supply a validation and defaulting tool . 17:38:41 why not for other OSes? 17:38:48 No. I mean tools officially supported by OCI. 17:39:01 vishh: I agree, it would be supercool 17:39:06 Once we move that to runc or docker or something else, it becomes implementation specific. 17:39:30 next topic? 17:39:33 vbatts|work: psst 17:40:23 #action everyone to add optional/required comments for fields that are missing them ;) 17:40:24 #info Everyone should continue reviewing :) 17:40:43 * wking disconnects the RobDolinMS mind-link 17:40:50 ;) 17:40:58 #topic vbatts - top-down docs 17:41:40 #info vbatts|work has been working on this 17:42:56 vbatts|work maybe add directories for logically grouping things? Maybe have a single spec.md? Expects a PR in the next week or so 17:43:09 #info vbatts|work hoping to have a PR in the next week or two 17:43:26 vbatts|work wants to make it easy to both get a high-level overview and to drill down onto a particular issue 17:43:50 #action vbatts|work to continue work on the top-down spec 17:43:58 @crosbymichael: "in vbatts we trust" ;) 17:43:58 RobDolinMS: Error: "crosbymichael:" is not a valid command. 17:44:09 #topic wking - lifecycle updates 17:44:12 crosbymichael: "in vbatts we trust" ;) 17:44:37 https://github.com/opencontainers/specs/pull/207 17:45:10 coly cow - that one comment has 16 footnotes! Gotta be close to a record!! 17:45:23 hahahahaha 17:45:25 * vbatts|work ohmans 17:47:05 #help people familiar with lifecycle to review wking's PR 17:47:53 I'll make any changes that folks need to see to get this landed without getting to deep in low-level issues 17:48:05 we can revisit those later after we have a high-level scaffold in place 17:48:17 #info maintainers should review the PR 17:48:50 #topic virt containers 17:48:56 vbatts|work: #topic? 17:49:27 https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/gS-nvHPwJQ8 17:50:26 Thanks wking :) 17:50:33 no problem 17:50:51 #topic mrunalp - bundle validation 17:51:06 should it go into the spec repo or be external 17:51:06 ? 17:51:09 mrunalp: ^ 17:52:15 you can also develop it externally and then merge it in later 17:53:05 mrunalp's approach: point at a bundle, launch a well-known process like cat, something else... 17:53:21 I don't think we want to rely on having 'cat' inside the bundle 17:53:50 what sort of things are we going to be validating for the bundle? 17:53:57 can't this just be a static config check? 17:54:12 or are we checking to see that the container has valid content in the rootfs? 17:54:47 give it a runtime (e.g. runC), generate a bundle using e.g. cat, run the bundle and check the resulting container 17:54:58 this sounds more like a runtime-validator, not a bundle-validator 17:55:39 vbatts|work: wants standard bundles that print pass/fail after running an internal check, and we can just launch those with the runtime being tested 17:55:48 mrunalp: has a working skeleton 17:56:08 currently a branch in ocitools 17:56:34 https://github.com/mrunalp/ocitools 17:57:08 vishh: if I want to know my resource constraints/identity/..., how does the application figure those out 17:57:27 mrunalp: currently mounting cgroups in the container, so the container can check there for those configs 17:57:37 vishh: do we want to mount the spec inside the container? 17:57:47 vishh: is the runtime updatable for a running container? 17:58:06 #action vishh to create and issue/mailing-list-thread to discuss further 17:58:48 Bunch of folks in Mt. View on/around Oct 21st; may coordinate a hacking session. 17:58:53 #topic vbatts - hacking session 17:59:00 ah, i'll just miss you. i get into sfo 10/24. 17:59:04 #info Bunch of folks in Mt. View on/around Oct 21st; may coordinate a hacking session. 17:59:26 can you give more details as it gets nailed down so people can make travel plans? 17:59:42 #action vbatts|work to send more details 18:00:08 see you 18:01:09 Looks like #195 hasn't landed yet (it's where I looked up the ocitools link). mrunalp's already LGTMed it, but can another maintainer take a minute to review/merge? It should be a quick review ;) 18:01:14 #endmeeting