22:00:48 #startmeeting 2016-12-07 discussion 22:00:48 Meeting started Wed Dec 7 22:00:48 2016 UTC. The chair is wking. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:00:48 Useful Commands: #action #agreed #help #info #idea #link #topic. 22:00:48 The meeting name has been set to '2016_12_07_discussion' 22:01:01 #chair mrunalp philips vbatts 22:01:01 Current chairs: mrunalp philips vbatts wking 22:01:40 mrunalp: there! 22:01:59 yes 22:02:37 dammit uberconference still doesn't work on my machine 22:02:58 cyphar, could you dial in? 22:03:14 yup, lemme grab my phone 22:03:56 #topic image-spec news 22:04:07 philips: we tagged rc3 yesterday with a unanimous vote 22:04:13 philips: still chugging away on rc4 22:04:43 https://github.com/opencontainers/image-spec/issues/482 22:04:44 #link https://github.com/opencontainers/image-spec/issues/482 22:04:52 #topic ChainID backgrond 22:04:57 * background 22:05:03 #link https://github.com/opencontainers/image-spec/issues/482 22:05:20 I want to put an implementation in the spec repo, because it's a little subtle. Where would that go? 22:05:58 stevvooe said that^ 22:05:59 wking, isn't everything in image tools a reference impl 22:06:31 stevvooe: the chain ID doesn't actually land on disk anywhere, but it is important for security 22:06:46 stevvooe: It is important, and I'd rather not have it be flying around on the image-tools repo 22:07:14 cyphar: my understanding was that we're keeping it in the OCI to avoid changing Docker configs 22:07:38 stevvooe: it's only used to identify the result of on-disk information, but we don't... something about CAS 22:08:02 (1pm is running over so I'm in the chat, but will join audio soon.) 22:11:05 stevvooe: image-tools has a long way to go before it stabilizes. I'm concerned about that stability, and want stable, well-known stuff like ChainID in the spec repo 22:11:57 so does stuff graduate to image-spec when it stabilizes? 22:12:07 stevvooe: no. The chainID is a stable part of the spec 22:12:14 stevvooe: the role of image-tools is not yet stable 22:12:36 stevvooe: image-tools stabilizing doesn't move things in. But subtle, challenging, or confusing stuff should go into the spec 22:12:49 stevvooe: image-tools should be useful, consumable 22:13:20 jlb13: put another way, it's perfectly fine to have clarifying code in the spec 22:14:03 stevvooe: code and spec in context is fantastic 22:14:23 stevvooe: people don't just consume DRY information and something pops out 22:15:03 jbl13: there is certainly precedence for this sort of thing 22:15:25 jlb13: it might be pseudocode or a narrative implementation and not Go, but it works. 22:16:04 mrunalp: any other image topics? 22:16:20 #topic runtime-spec command line API 22:16:34 Status of console PR/CLI API. 22:17:23 #link https://github.com/opencontainers/runc/pull/1018 22:17:40 crosbymichael: I was just wondering why it's still a Unix socket on disk 22:17:54 cyphar: I was trying some other approaches (e.g. passing around file descriptors) 22:18:12 cyphar: but the only way to do that is to keep the FD open when you fork/exec, but that restricts uses 22:18:36 cyphar: rather than the runtime opening the socket, you have to pass the FD to the runtime parent and then hand that on down 22:18:55 cyphar: there was another approach [missed some words], but I'm worried that might break 22:19:06 crosbymichael: How does it work now? It gets a path and init opens it 22:19:37 cyphar: I think the way it works now is that the init parent opens it... I'll have to check... 22:19:48 crosbymichael: if the host opens it, you're still passing it down to the init 22:20:09 cyphar: The connect code is in the main process, but I'm trying to remember how it gets the path... 22:20:52 cyphar: Ok. There are two sockets: one inside runC, and the parent passes the console socket through runC's internal socket 22:21:29 crosbymichael: it seems weird. Why not open in the host process and inherit it through? 22:21:52 cyphar: we need the internal socket for synchronization 22:22:00 cyphar: the console socket is different 22:23:49 mrunalp: one thought from last week is that the socket is just for a one-time event 22:24:08 crosbymichael: you send the master down and then never use this again 22:24:26 cyphar: we may want to use it for event pushes later. I was trying to keep that door open 22:24:48 #link http://github.com/opencontainers/runtime-spec/pull/508 22:25:02 cyphar: and currently logging doesn't work without the console changes, and stuff like that 22:26:52 I don't think this socket is going to be useful for update, because you won't be able to send anything after you exec the user-specified code 22:27:09 crosbymichael: using a filesystem socket pulls in a lot more setup/cleanup/opening code 22:27:18 crosbymichael: vs. socketpair() 22:27:48 cyphar: we can pass via FD, but then you'd need a wrapper for testing 22:27:59 I have no problem with a wrapper for testing 22:28:27 cyphar: we can merge the PR as it stands now, and have a 30-line frontend change to switch between filesystem sockets and FDs 22:28:50 crosbymichael: the testing change shouldn't be too bad, since [...missed some words...] you'll need a wrapper anyway 22:29:01 e.g. to collect the container exit code^ 22:29:19 crosbymichael: you don't have to have a calling process to get the whole flow 22:29:49 crosbymichael: if we want to merge it and then land FD passing later (to keep a big rebase down) 22:29:56 mrunalp: whatever is easier for cyphar 22:30:04 cyphar: I think it's merge-able now 22:30:21 crosbymichael: and it handles detached and non-detached now? 22:30:56 cyphar: it uses the same internal communication as before. The only change is passing the master FD out 22:31:19 crosbymichael: we can land this, and then file a new PR for the FD route to see how it works 22:31:49 mikebrow: So keep both? Or maybe take out the path-based approach later? 22:31:57 crosbymichael: We'd only keep one approach 22:32:11 #topic runtime-spec anchor PRs 22:32:33 #link https://github.com/opencontainers/runtime-spec/pulls?utf8=%E2%9C%93&q=is%3Aopen%20is%3Apr%20author%3ARobDolinMS%20anchor%20tags 22:32:53 mrunalp: runtime spec maintainers should review and (assuming they don't see any problems) LGTM and merge 22:32:56 mrunalp: thoughts? 22:33:09 #topic security issues 22:33:12 when we have a moment, wanted to update on manifest-list/refs change 22:33:22 mrunalp: I think it makes sense to keep this on the list, and not discuss them here 22:33:52 #topic image-spec refs / index 22:34:05 https://github.com/opencontainers/image-spec/pull/438#issuecomment-264035961 22:34:27 stevvooe: we need to work this out before the release, because it's a bigger change 22:34:36 stevvooe: also removing media types from self-describing types 22:34:49 #link https://github.com/opencontainers/image-spec/pull/411 22:36:13 stevvooe: some of these problems are coming out as we get into implementation 22:36:23 stevvooe: refs are kindof useless, with the limited character space 22:36:50 stevvooe: the annotations method is better, but we need a full spec for that (with descriptor and manifest-list changes) 22:36:59 stevvooe: if you're auto-detecting, you're probably going down the wrong path 22:37:02 stevvooe: is that clear? 22:37:21 philips: Those are the issues I'm concerned about too 22:37:43 philips: someone should write a TL;DR on the media type front 22:38:04 cyphar: can we fix the descriptor/peek-inside mediaType overlap first? 22:38:26 stevvooe: that assumes that the media types in the other objects are consistent 22:38:40 stevvooe: you shouldn't be reading random data off the disk and assuming you know it's type 22:38:52 stevvooe: part of that is not embedding the type inside the content 22:39:07 stevvooe: and you might be able to safely refer to it with a number of different types depending on the context 22:39:38 stevvooe: I do want to internalize some of the impacts you've seen, cyphar. But we should be able to do that without peek-inside mediaTypes 22:40:05 stevvooe: mediaType snuck into the config in the fall of 20… [something]. We need to stamp it out before it causes even more issues 22:40:18 stevvooe: it's just going to create security issues 22:40:38 cyphar: I've changed my mind on this since commenting on the issue. 22:41:04 cyphar: I was doing autodetection because wking's CLI tool would just dump the raw blob 22:41:16 cyphar: but if you stick to descriptors everything is nice 22:41:29 stevvooe: exposing the CAS is weird. I'm trying to find a better model 22:41:38 stevvooe: Git embeds the type in the blob itself 22:42:05 stevvooe: it's good to here that descriptors worked out for you, cyphar, and I think we want to remove mediaType from everything except descriptors 22:42:18 stevvooe: and we need docs in the spec to explain how people should be handling this 22:42:44 philips: we need an issue to say that the spec doesn't allow for reverse indexing by media type (you can't go from a digest to it's media type) 22:43:01 philips: and we need [something else], but #411 seems like the exact opposite 22:43:22 #action philips to file issues for the two mediaType changes needed to resolve the #411 discussion 22:43:55 stevvooe: and thanks to cyphar for umoci, because the feedback is helping a lot 22:44:08 mrunalp: anything else? 22:44:24 #topic runtime-spec anchor PRs again 22:44:32 RobDolinMS: was there feedback? 22:44:42 mrunalp: I pinged them earlier, and there weren't any objections 22:45:21 stevvooe: is there an image-spec version of this? 22:45:38 RobDolinMS: I paused for feedback before pushing forward further 22:45:50 #link https://github.com/opencontainers/runtime-spec/issues/634 22:45:53 #link https://github.com/opencontainers/runtime-spec/issues/635 22:46:00 RobDolinMS: ^ this is a good example 22:46:13 stevvooe: this looks good. And we don't end up with deep section numbering 22:46:34 RobDolinMS: I prefixed these with filenames, so the one-file PDF has unique anchors 22:46:47 RobDolinMS: And I labeled each entry in bulleted lists 22:47:26 RobDolinMS: So you can link to the entry instead of linking to the list as a whole 22:47:29 https://github.com/opencontainers/image-spec/pull/423 22:47:44 stevvooe: we want to land this^ before doing the anchors for image-spec 22:47:47 mrunalp: anything else? 22:47:54 np 22:48:04 #endmeeting