21:03:33 #startmeeting OCI 31/8 21:03:33 Meeting started Wed Aug 31 21:03:33 2016 UTC. The chair is mrunalp. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:03:33 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:03:33 The meeting name has been set to 'oci_31_8' 21:03:37 mrunalp: chair me? 21:03:37 #topic Updates on console/CLI API, if any. 21:03:42 #chair wking 21:03:42 Current chairs: mrunalp wking 21:03:44 thanks 21:04:28 I'm here 21:04:29 joining 21:04:48 https://github.com/opencontainers/runtime-spec/pull/543 21:05:06 #topic SHOULD for reverse-DNS names 21:05:19 * vbatts here now 21:06:10 duglin: We have SHOULD language, why not use it? 21:06:18 duglin: lets change the SHOULD to a MUST. What happens? 21:09:10 wking, Should not impose on external spec authors 21:09:21 duglin, This is an encouragement 21:09:30 vbatts concurs 21:09:36 Which Issue # or PR # is specifically addressing the reverse-DNS and SHOULD question ? 21:10:05 https://github.com/opencontainers/runtime-spec/pull/510 21:10:29 I need to add a line about reverse DNS 21:16:23 " SHOULD This word, or the adjective "RECOMMENDED", mean that there 21:16:23 may exist valid reasons in particular circumstances to ignore a 21:16:23 particular item, but the full implications must be understood and 21:16:23 carefully weighed before choosing a different course. 21:16:23 " 21:16:33 https://www.ietf.org/rfc/rfc2119.txt 21:16:54 wking: Less "should not impose on external spec authors" than "why bother with a SHOULD we never intend to test?" 21:17:05 #topic image-spec 0.5.0 21:17:26 #link https://github.com/opencontainers/image-spec/issues?q=is%3Aopen+is%3Aissue+milestone%3Av0.5.0 21:18:01 I think we can get this one merged with some LGTM's from maintainers: https://github.com/opencontainers/image-spec/pull/226 21:18:14 vbatts: what's the timeline for 0.5.0? 21:18:21 is vbatts cutting out for others too? 21:18:31 stevvooe: my big question is refs vs. tags, but philips has clarified that for me 21:18:48 duglin: yes 21:18:49 philips: in that PR we just need another LGTM 21:19:01 ok wasn’t sure if it was just my line 21:19:27 duglin: sorry. I'm thinking my internet at the house is silly. 21:20:22 with today’s “great” technology you never know where the issues are. 21:21:29 we might want to move this hostname restriction to a runtime-spec SHOULD (I'll do that) 21:21:41 not to rehash things but do we reserve org.opencontainers.* or org.opencontainers/* or both? 21:22:19 duglin: I think folks liked the . form. Folks thought / was weird with reverse-DNS (I'll dig up a link for you after the meeting) 21:22:42 stevvooe: what about different types of refs? refs/tags, refs/names, ...? 21:23:04 philips: that's fine, or we could create a new directory called images/ or whatever 21:23:17 stevvooe: if we did that, we'd rename refs/ to tags/ and be done with it 21:23:24 vbatts: are we loosing the word refs? 21:23:36 ‘cause I see kube using things like: pod.alpha.kubernetes.io/init-containers 21:23:36 stevvooe: yes, unless you see a problem 21:23:57 vbatts: not a big problem. But I kind of like the flexibility of generic refs, with tags just being one type of ref 21:24:27 stevvooe: the Docker save format is a little wild-west at the top level, so I sympathize with that argument 21:24:48 stevvooe: but we can merge the tag note 21:25:01 vbatts: I like keeping things under refs/ 21:25:21 philips: I think that closes #173, now that the language is clear 21:25:41 philips: stevvooe, do you need help on #208? 21:26:11 stevvooe: I was waiting to see if folks had a good reason for hash sharding 21:26:17 philips: I didn't see any reasons like that 21:26:24 stevvooe: can someone else do the code for #208? 21:26:41 philips: runcom? Can you do the code? 21:26:44 runcom|afk: yes 21:27:50 vbatts: should parsers fail if they find duplicate entries in a tar stream? 21:28:04 vbatts: shuold you keep a set of all entries you'd seen, so you can detect duplicates? 21:28:21 philips: I think this is pretty much a MUST NOT 21:28:43 vbatts: if you have a duplicate entry, you get undefined behavior, and shame on you 21:28:57 stevvooe: I was mostly concerned about memory if you keep a set of all entries 21:29:32 vbatts: I don't think we need to require that, just make it undefined 21:29:57 Do implementers have to check this? "MUST raise an error" vs. "handling is undefined" 21:30:36 vbatts: "handling is undefined", so it's up to the implementer 21:30:47 stevvooe: O(N) for entries is mostly small 21:31:40 vbatts: I'll put together a vote for 0.5.0 tagging once we get these out 21:31:50 stevvooe: were there major objetions to #212? 21:31:55 https://github.com/opencontainers/image-spec/pull/212 21:31:57 philips: no major objections 21:32:05 stevvooe: this is mostly cleanup 21:32:09 philips: I think it's ok 21:32:46 #topic next image-spec milestone 21:33:03 philips: move #212 into 0.5.0? 21:33:09 stevvooe: yeah, I can fix that today 21:33:22 philips: what about extensions? 21:33:28 duglin: I should be able to get that done soon 21:33:54 philips: I'll take a swing at #220 21:34:08 philips: we need to figure out what else has to happen before 1.0 stuff starts rolling 21:34:14 philips: other discussion points? 21:34:24 #topic separate tool repos 21:34:36 #link https://github.com/opencontainers/tob/pull/18 21:34:43 mrunalp: RobDolinMS, do you want to talk about this? 21:34:47 https://github.com/opencontainers/tob/pull/18 21:35:15 mrunalp: I don't know what happened at the face-to-face, but this PR looks good to me 21:35:35 philips: motivation is just to decouple tooling from specs so they can iterate independently 21:35:58 I'm on the line and can hear folks, but sounds lik you guys can't hear my audio 21:36:52 The PR currently lists the proposed repos as: runtime-tools and image-tools 21:36:52 hit the magic buttons to unmute 21:37:01 i forget them 21:37:31 https://github.com/opencontainers/tob/pull/18/files#r76834447 21:37:39 philips: no strong opinion, but we should pick one 21:37:52 mrunalp: so we'll wait for the TOB 21:38:01 Someone (Antonio?) had asked for them to be plural 21:38:13 #endmeeting