21:03:27 #startmeeting 2016-07-20 discussion 21:03:27 Meeting started Wed Jul 20 21:03:27 2016 UTC. The chair is wking. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:03:27 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:03:27 The meeting name has been set to '2016_07_20_discussion' 21:03:35 #topic image-spec 0.4.0 21:03:57 stevvooe: I've moved the whiteout docs onto the 0.4.0 milestone, let me know if anyone has problems with that 21:04:23 stevvooe: There is an open PR about limiting integers to int64, but I'm not sure what the current status of that is 21:04:43 stevvooe: there hasn't been more discussion about naming or signing. Are we punting those? 21:05:06 vbatts: I'm not sure what the int64 hangup was 21:05:29 vbatts: I thought naming/signing was getting pushed into an optional layer. We wanted the ability to add it later without breaking things 21:05:57 stevvooe: do we need an action item to sketch naming/signing in broad strokes so we can talk about forward compat? 21:06:20 i said "do we need to define the shape of naming/signing?" 21:06:26 vbatts: scopio (wking: maybe a typo?) has some of this in place, we should look at that to frame the discussion 21:06:26 :) 21:06:32 skopeo 21:07:37 stevvooe: do we tackle this after we have an image layout in Docker? 21:08:22 vbatts: I don't know. You could parallelize them with blob/refs with signature information... 21:09:00 stevvooe: the spec is missing parts, but we probably want Docker save/load to the image layout in a branch somewhere 21:09:25 vbatts: Docker save/load mock up sounds good 21:09:36 stevvooe: there's a containers/image that has some work in progress? 21:09:45 url: https://github.com/containers/image 21:10:03 vbatts: that's part of skopeo a tool that can pull from Docker / OCI / etc. and lay things out for runC 21:10:21 vbatts: if there is support for that in Docker as well, that would be good for compatability 21:10:25 It is a library that was pulled out of skopeo 21:10:37 stevvooe: should we take this offline? 21:10:40 skopeo is a utility built on top of that library 21:11:06 thanks mrunalp / stevvooe for correcting me when I get things wrong ;) 21:11:24 mrunalp: other image-spec topics? 21:12:41 vbatts: I'd like to get type-export landed, but there's some pushback there 21:13:13 vbatts: if anyone has spare cycles, ping us with things you want in 0.4.0 21:13:24 vbatts: otherwise stevvooe and I will assign as we see fit 21:13:32 vbatts: I arbitrarily put it on the 27th 21:13:58 Appreciate all of the work you're doing vbatts for managing release mechanics 21:13:59 vbatts: comment on an issue you want in 0.4.0 if you don't have permissions to assign it yourself 21:14:02 https://github.com/opencontainers/runtime-spec/pull/513/files 21:14:09 #topic runtime-spec command line API 21:14:23 https://github.com/opencontainers/runtime-spec/pull/511 21:14:29 https://github.com/opencontainers/runtime-spec/pull/513 21:15:06 cyphar: --console in runC works by having the runtime-caller creating a virtual terminal, and --console is for passing the slave end into runC 21:15:18 cyphar: but that has some namespace issues, so we might change that at some point 21:15:31 cyphar: but we need an ability for the caller to tell runC which console to use 21:17:50 why do you need --console instead of duping the slave over the standard streams before launching runC 21:18:10 cyphar: I'm not sure. We do dup over the slave bits, but we don't do it the way you describe 21:18:49 I was talking about ccon's handling, and didn't transcribe myself, but it's written up here: https://github.com/wking/ccon/tree/v0.4.0#terminal 21:19:06 mrunalp: the pair could be created inside the container 21:19:40 mrunalp: this is why tty's don't work in runC exec 21:20:10 crosbymichael: so when we create this, we setns on the mount namespace, open the terminal, and then..? 21:20:21 did anyone get a chance to review my PR: https://github.com/opencontainers/runtime-spec/pull/511 ? 21:21:32 runc run -d --console /dev/pts/ptmx test_busybox 21:21:37 ^ works 21:21:52 mrunalp: it could potentially be done by the caller 21:22:09 cyphar: we need an API for the caller to get the master 21:22:30 (both libcontainer and the runC runner) 21:23:06 Daniel Dao: We don't want the container to interrupt the I/O 21:23:38 cyphar: the '--console UNIX_SOCKET' approach might work (with runC pushing the master into that socket) 21:24:03 mrunalp: where do we have this discussion? 21:24:17 mrunalp: we'll need this specified for compliance testing in ocitools 21:24:33 cyphar: the spec is pretty sparse around process.terminal anyway 21:24:46 https://github.com/opencontainers/runtime-spec/pull/518 21:24:58 cyphar: lets get something working in runC and then come back and figure out how to put it into the command-line spec 21:26:29 I think we should focus on the container view in config.md, and just say "standard streams will be a terminal if you set process.terminal". We can talk about the command line API later 21:26:48 cyphar: we'll need clarity around the command-line API soon 21:27:34 duglin: how much longer do we think this should take? 21:28:22 mrunalp: what's the harm with supporting both approaches now? 21:28:35 cyphar: runtime-callers and testers won't know which is ok if we don't specify one 21:29:30 cyphar: what about --pid-file vs. state? 21:29:51 https://github.com/opencontainers/runtime-spec/pull/513#issuecomment-232857404 21:29:58 ^ my "why do we have a --pid-file?" 21:30:22 crosbymichael: it's a standard way for interfacing with systemd, etc. 21:31:21 #action wking will reroll #513 to add --pid-file 21:32:02 cyphar: how do we test without 'run' in the spec? Who holds the streams open? 21:32:19 mrunalp: the caller handles that and exit-code collection. I'll add support to ocitools 21:32:38 #action cyphar to look at --console vs. the command line spec in the next week or so 21:34:58 what about 'version'? Do we drop it? 21:35:07 duglin: I don't think we need it for interop 21:36:00 duglin: any runtime is going to have some way to do that. Do we need to agree on the API? 21:40:42 duglin: -b is probably going to be popular, so we may want to require it be portable 21:41:13 we can always add it later; it's hard to pull it out later (and I don't expect many folks will be typing this out by hand) 21:41:18 duglin: agrees to punt on -b 21:41:22 >> ^ works 21:41:37 the command: runc run -d --console /dev/pts/ptmx test_busybox 21:41:40 mrunalp: other topics? 21:41:50 mrunalp: any other blockers for 1.0? 21:42:00 crosbymichael: nothing off the top of my head 21:42:28 mrunalp: figuring out the console will help ocitools tie up some loose ends 21:42:38 #endmeeting