21:00:15 #startmeeting 2016-08-10 discussion 21:00:15 Meeting started Wed Aug 10 21:00:15 2016 UTC. The chair is vbatts|work. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:00:15 The meeting name has been set to '2016_08_10_discussion' 21:00:17 IT'S OCI TIME 21:00:32 aww yiss 21:01:05 I've missed y'all since DockerCon :( 21:01:13 hurry someone hack up https://media.giphy.com/media/WQD6NEEsVTvxK/giphy.gif to say OCI instead 21:03:49 vbatts|work: chair me? 21:04:45 philips: I've submitted https://github.com/opencontainers/image-spec/pull/195 with a ChangeLog for 0.4.0 21:05:23 philips: Then we'll have a vote on tagging 0.4.0 21:05:44 vbatts|work: it would be ideal if the ChangeLog could be automated 21:06:00 philips: Automated ChangeLogs aren't very useful (just use Git log) 21:06:10 philips: consumer-useful is different from developer-useful 21:06:29 vbatts|work: and yeah, it should close on the 17th 21:07:00 mrunalp: there was a question around certification and architectures? Should we spell it out? 21:07:18 philips: why does the architecture matter for images? 21:07:33 philips: the image tooling doesn't have to execute the image content 21:07:52 mrunalp: if you have a runtime that only works on x86_64, should there be certification language around that? 21:08:18 philips: for the runtime, we'll obviously need to certify runtimes for a given architecture, and the spec needs to be particular about that 21:08:40 https://github.com/opencontainers/runtime-spec/pull/527 21:09:36 The arcitecture and OS (both part of the platform) should be part of the certificate 21:09:47 mrunalp: I think we want language about this to land before 1.0 21:10:09 philips: I don't see why this matters for the image spec 21:11:40 mrunalp: I can roll this into #527 21:12:01 mikebrow: I'm not happy with unconditionaly-compliant 21:12:10 #chair wking 21:12:10 Current chairs: vbatts|work wking 21:13:22 #topic compliance with the runtime spec 21:13:37 #action mrunalp to handle architecture language in #527 21:14:16 mrunalp: cyphar? 21:14:32 #topic console updates 21:14:36 mrunalp: crosbymichael thoughts? 21:14:47 crosbymichael: cyphar and I have been busy, so we should probably punt again 21:14:54 mrunalp: we can revisit next week 21:15:00 mrunalp: other topics? 21:15:41 #topic tar ordering in the image-spec 21:15:57 stevvooe: we'll need new language to clarify order of application (e.g. a tar with two resources with the same path) 21:16:15 stevvooe: we want to only apply one of those to the resulting layer. With tar it's usually the latest entry 21:16:31 stevvooe: with opaque files it's a bit more complex, but we'll want language for that 21:16:48 https://github.com/opencontainers/image-spec/issues/128 21:16:59 stevvooe: I'll probably implement image-spec#128 soon 21:17:07 philips: Can we just require no duplicate entries? 21:17:33 stevvooe: the algorithm isn't very fancy. We just need generic tar handling + opaque bubblign 21:17:54 philips: I'm saying it's easier to require no duplicate dentries unless we find a great use case 21:18:22 stevvooe: I can't think of a good use case, unless we have existing cases and want to preserve backwards-compat. Have you seen it? 21:18:36 vbatts|work: I've only seen it in the context of "look, tar lets you do this" 21:18:51 vbatts|work: There isn't a modern tool that creates duplicate entries in the tar stream 21:19:14 stevvooe: If we're confident with that, we can add that requirement, but I'm concerned about backwards compat 21:19:28 philips: How does Docker v2.2 handle this? 21:19:39 stevvooe: Docker v2.2 was more about manifests than about layers 21:19:51 stevvooe: the Docker layering spec doesn't cover a lot of these details 21:20:23 stevvooe: I'm fine with either "resources are unique" or "this is how ordering is handled", but we need to do something 21:20:45 tianon: We could say "in the case of duplicate entries, behavior is undefined", and not bother testing that 21:20:59 philips: the trick is that we're already in custom tar-library land because of the opaques 21:21:03 tianon: ah, right 21:21:35 philips: I'll comment on the issue, but I'd rather block duplicates, but am ok with documenting something that is Docker-compatible 21:21:49 vbatts|work: since Docker 1.8 tarsplit will fail with errors on duplicates 21:22:22 stevvooe: we ran a huge job around 1.8 / 1.9 looking at layers. Before Docker 1.6 there were wierd tar entries around temp files and repeated entries 21:22:43 stevvooe: so I suspect modern Docker issues are fine, and we can deal with any fallout from older images 21:22:46 vbatts|work: I like that 21:23:17 vbatts|work: The only use case ever for duplicates were exploits or literally writing to tape where you don't want to rewind 21:23:39 stevvooe: either vbatts|work or I will get this submitted 21:23:41 vbatts|work: right on 21:23:48 taking a list of tar layers and smashing them together as-is could be amusing, but it's not a strong or even real-world use case O:) 21:24:04 vbatts|work: anything else? 21:24:38 vbatts|work: can you #endmeeting 21:24:45 #endmeeting