22:05:32 #startmeeting 2016-11-30 discussion 22:05:32 Meeting started Wed Nov 30 22:05:32 2016 UTC. The chair is wking. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:05:32 Useful Commands: #action #agreed #help #info #idea #link #topic. 22:05:32 The meeting name has been set to '2016_11_30_discussion' 22:05:37 I missed the first few minutes... 22:05:48 #topic runtime-spec command line API 22:05:54 #link https://github.com/opencontainers/runtime-spec/pull/513 22:06:08 #action crosbymichael to comment about socket handling in the PR 22:06:30 mrunalp: other thoughts for the command line API PR? 22:06:41 crosbymichael: I can't think of anything else that we were missing 22:06:50 #topic anchor updates 22:07:57 RobDolinMS: I'm happy to keep going with the Markdown anchors for v1 22:08:16 mrunalp: works for me, any objections? 22:08:26 Works for me too, as long as I'm not doing the work ;) 22:08:47 #action RobDolinMS to work up PRs for Markdown anchors for the rest of runtime-spec 22:09:09 #topic runtime testing feedback 22:09:38 RobDolinMS if we're getting started from scratch, where should those docs go? The README? A wiki? 22:09:48 mrunalp: runtime-tools README is a good place 22:09:57 +1 to putting the notes in the runtime-tools README 22:10:19 stephenrwalli: RobDolinMS and I worked up Ubuntu and Fedora notes already 22:10:30 #action stephenrwalli to PR Fedora notes for runtime-tools 22:10:42 #action RobDolinMS to PR Ubuntu notes for runtime-tools 22:11:09 stephenrwalli: we have a dependency on the Go capabilities library which doesn't have an open-source license 22:11:49 #topic image-spec rc3 22:11:57 vbatts: I posted a vote for this today 22:12:11 stephenrwalli: 22:13:22 stephenrwalli: going back a topic, gocapability is 2-clause BSD: https://github.com/syndtr/gocapability/blob/master/LICENSE 22:14:07 vbatts: having some sort of notes about naming would be good for 1.0 (even if it's just "naming is not defined") 22:14:53 stevvooe: If we were working on ELF or PDF, do those specs talk about distribution over HTTP 22:14:56 ^ probably not ;) 22:15:15 stevvooe: the image format is based on Docker tech, but... 22:15:31 [stevvooe dropped] 22:15:39 reloading 22:16:35 chrome stopped recognizing my mic 22:16:36 once sec 22:17:44 wking: You are completely correct. My apologies, All. 2-Clause BSD. I stand corrected. 22:17:59 i'll be in seattle as well 22:18:01 one sec 22:18:05 stephenrwalli, yep, I checked that as well 22:18:21 chrome sucks 22:19:05 stevvooe: You can direct dial into the meeting from a land line or mobile: 415-968-0849 22:19:37 philips: I'm not clear on the index use case 22:20:09 vbatts: If you have a tar image with an early oci-layout index, you can exit early on missed lookups (without reading the tar file) 22:20:16 * the whole tar file 22:20:46 vbatts: also a flat-pack use-case with lots of reference objects (assorted GNOME runtimes, Gedit runtimes, etc., etc.) 22:20:50 "Due to the size of the call, you have been auto muted to improve call quality." 22:21:19 vbatts: instead of walking over HTTP you could fetch a single, required file and use the optional index to find your ref list 22:21:57 vbatts: it's for ref-listing efficiency and for packing descriptor annotations 22:22:36 #link https://github.com/opencontainers/image-spec/pull/438 22:22:47 stevvooe: what's the role of refs/ if we already have an index? 22:23:01 vbatts: it does kindof clobber that 22:23:44 vbatts: the refs/ directory has a named descriptor, whereas the index... all the blobs or just the refs or whatever... more for people who want a single source for fetching what's in the layout 22:24:16 vbatts: it's painful/impossible to walk refs/ in some cases 22:24:20 stevvooe: so can we pick one? 22:24:36 vbatts: get rid of refs/ (if we replace it with an index) 22:24:46 stevvooe: refs/ is nice because merging is easy 22:24:56 stevvooe: but your point about HTTP fetching is an interesting thing 22:25:07 stevvooe: although it's looking a lot like a manifest list... 22:26:14 stevvooe: we should compare this with the Docker safe format too 22:27:47 stevvooe: I guess what I'm saying is that this should be a full-blown object (generalizing manifest list) and replacing refs/* with a well-known path 22:27:51 https://github.com/opencontainers/image-spec/blob/master/manifest-list.md 22:28:06 vbatts: I'll have to check once I can get to my work station... 22:28:14 philips: I see what you're saying, stevvooe 22:28:33 stevvooe: if we add annotations as an optional descriptor field, then manifest lists cover this case 22:28:51 vbatts: and we're replacing refs/* with... a new entry in oci-layout? Or a refs.json? 22:29:12 vbatts: that would be like manifest.json in the current Docker format 22:29:29 stevvooe: I think index.json, because there are no refs (naming would be via annotations) 22:29:37 https://github.com/opencontainers/image-spec/pull/438/files 22:30:02 #action stevvooe to add comments to the PR about a manifest-list approach 22:31:35 I think we need to keep first class naming for things like 'unpack v1.0' 22:32:14 stevvooe: but refs are not reliable, since we don't have verifiable names 22:32:30 stevvooe: image tags have a larger character set, and image names are more than just the tag 22:32:49 stevvooe: doing this by annotation lets applications figure out how they want to handle naming 22:33:11 Is image-tools unpack just going to be by digest? 22:33:29 stevvooe: I think there will be tools that let you select a portion of the index by annotation 22:33:53 stevvooe: you can do this without a specified naming scheme, just "unpack the images matching this selector..." 22:34:31 so something like "unpack com.example.name=v1.0"? 22:34:46 stevvooe: the main problem with refs is that there are many namespaces, so you need translations between them 22:35:01 stevvooe: if you just declare what it is for each system there's no need to meet in the middle 22:35:14 stevvooe: I think this is a good change, and I'll add commentary to the PR 22:36:26 stevvooe: this is a big change (but I think it's the right change). Let's make sure we handle it appropriately 22:37:06 vbatts: with the vote out for image-spec rc3 and the holidays coming up... 22:37:55 vbatts: future RCs and 1.0 are probably in mid/late January 22:38:32 vbatts: there's also in-flight work about integrating image-layout support into Docker 22:38:48 stevvooe: the draw-back to image.json is that it's unverifiable 22:38:51 philips: why? 22:39:13 stevvooe: say you get a URL without a hash/verification/signature. You download, unpack, and don't trust index.json 22:39:33 stevvooe: presumably someone will be hashing/signing the index.json with a side-declaration 22:39:54 stevvooe: I think this gets back around to defining a framework for signing, and we don't need to address this before 1.0 22:40:15 philips: this is like refs now, where there's no verification unless you have out-of-band signatures 22:40:26 stevvooe: it's easier if it's in one file 22:40:44 philips: there are a bunch of random, open PRs which need attention too 22:41:01 https://github.com/opencontainers/image-spec/pull/451 22:41:11 #topic Shipping runtime-spec configs 22:41:16 #link https://github.com/opencontainers/image-spec/pull/451 22:41:29 stevvooe: this is a bad idea 22:41:32 philips: yeah, never do that 22:41:44 stevvooe: it seems like a good idea, but there's so much host-specific stuff 22:42:03 stevvooe: translating from the image-config to the host-config is a great security barrier 22:42:19 stevvooe: if we look at the Docker image/host config, there are many fewer image configs 22:42:47 stevvooe: the OCI spec split distribution and runtime, but the image config and runtime config should be separate (but translatable 22:43:16 philips: The spec at one point separated host-specific from runtime-specific, but some things are specific to a single machine/run 22:44:05 I think you can handle this with sanitization 22:44:18 stevvooe: this is like building a salad bowl with a sieve, plugging all the holes 22:44:37 stevvooe: if you let things go through and then whitelist/blacklist, it's going to be bad 22:45:16 are you concerned with people who don't sanitize, or about people who sanitize poorly? 22:45:28 YES! XML lives! 22:45:30 stevvooe: I'm concerend that you don't understand the ramifications of this proposal 22:45:38 vbatts: we need XSLT... 22:45:50 crosbymichael: we have two specs for this very reason 22:46:03 crosbymichael: this is a horrible idea 22:46:52 vbatts: we were talking about this in San Francisco last year, with hints at memory requests and such in annotations. But it would be implementation specific 22:47:05 vbatts: so it would be "your implementation chose to poke a security hole" 22:47:23 philips: I think we have a consensus and just need to post a clear reason 22:47:35 #action stevvooe to post a comment explaining why this is a bad idea 22:48:57 So with runtime specs off the table, I think we need to define how the translation should work in more detail 22:50:23 philips: there aren't many fields to map, so that shouldn't be a problem 22:50:57 stevvooe: command is pretty straightforward. Entrypoint is always confusing. Volumes is the only real unknown 22:51:11 philips: Volumes and ExposedPorts are hints to the UX, and not directly actionable 22:51:51 We might also have to expand the image config to cover other OSes (and VMs?) 22:51:59 philips: I'll start with the more clearly scoped stuff first 22:53:25 #topic image-tools maintenance 22:53:40 RobDolinMS: I hit some snags trying to run this 22:53:45 vbatts: open an issue? 22:53:56 #action RobDolinMS to open an issue about image-tools snage 22:53:58 *snags 22:54:08 [vbatts leaves] 22:54:15 #endmeeting