21:01:03 #startmeeting 2016-08-05 discussion 21:01:03 Meeting started Wed Oct 5 21:01:03 2016 UTC. The chair is wking. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:03 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:01:03 The meeting name has been set to '2016_08_05_discussion' 21:01:14 #chair mrunalp vbatts RobDolinMS 21:01:14 Current chairs: RobDolinMS mrunalp vbatts wking 21:02:33 https://github.com/opencontainers/runtime-spec/pull/518 21:02:42 #topic /dev/console handling in runtime-spec 21:02:49 #link https://github.com/opencontainers/runtime-spec/pull/518 21:03:16 mrunalp: do we need a switch to toggle bind mounting? 21:03:31 crosbymichael: I don't think we need a special case in the docs. Do we create the bind mounts by default? 21:03:46 second sentence there was mrunalp^ 21:04:06 crosbymichael: The bind-mount doesn't matter. It's that way because we used to pass in a terminal from outside 21:04:14 mrunalp: so we should leave it up to the runtime? 21:04:28 crosbymichael: yeah, it can be bind mounted or the runtime can create the terminal inside 21:04:50 mrunalp: with the bind mounting, we're talking about bind-mounting the slave (regardless of whether it's from outside or inside) 21:05:02 mrunalp: the real console (c5/1) is not namespaced, and that's dangerous 21:05:35 crosbymichael: I'm not saying we should mount c5/1, I'm saying that something has to be at /dev/console, but what is implementation-determined 21:05:57 crosbymichael: in cyphar's runC PR it's bind-mounting the internally-sourced pseudoterminal slave 21:06:37 I think something should at /dev/console there regardless of process.terminal 21:10:55 I think this topic is upsetting someone :-) 21:11:05 Is there a reason why logging to the system console would depend on whether the container process needed a terminal? 21:11:21 the baby in the background is clearly not happy about it 21:11:35 :D 21:13:46 crosbymichael, legacy applications use /dev/console 21:13:53 crosbymichael, It is not just for logging 21:15:30 https://github.com/opencontainers/runtime-spec/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.0.0 21:15:38 I see no /dev/console hits in OpenSSH 7.2 21:15:46 https://github.com/opencontainers/runtime-spec/pull/513 21:15:59 #topic runtime-spec 1.0.0 milestone 21:16:08 mrunalp: I think #513 should be part of 1.0 21:17:36 mrunalp: any other PRs for 1.0? 21:18:02 https://github.com/opencontainers/runc/issues/1094 21:19:54 mrunalp: there's also https://github.com/opencontainers/runc/pull/1082 21:21:00 crosbymichael: I think most of the people use the cgroups package 21:21:37 vishh: kube uses libcontainer. If upstream libcontainer doesn't support that use case, we might fork it. 21:21:52 I'm not sure who else is using it, but we should at least keep the cgroups interfaces 21:22:05 crosbymichael: I'm just suggesting changing libcontainer to depend on the runtime-spec 21:22:17 vishh: we need a way to extend the spec to add more features to libcontainer 21:22:32 crosbymichael: maybe we can embed the struct to get some breathing room 21:22:46 vishh: that's fine. As long as there's a way to extend cleanly, that's ok 21:22:59 mrunalp: I don't think libcontainer extends the spec now 21:23:26 vishh: I see the argument for leaning on the spec, but I want the ability to safely extend the spec to be there if we need it 21:23:31 mrunalp: maybe post 1.0? 21:23:47 mrunalp: any other 1.0 PRs? 21:24:18 mrunalp: any other topics? I don't see any image people... 21:24:29 vishh: what is the timeline for 1.0? 21:24:47 mrunalp: we have a few open PRs (mostly around console and the API) 21:25:02 mrunalp: I don't know if there's a timeline beyond those blockers 21:25:16 mrunalp: maybe target end of October? 21:26:37 I don't know if landing #513 resets the rc* clock. We probalby want to let that cook a bit after it lands 21:27:01 mrunalp: With the console stuff landing soon, we'll have something very close to 1.0 by the end of the month 21:27:20 RobDolinMS: we should look at interoperable implementations (e.g. having multiple rc2-based tools that work together) 21:27:31 mrunalp: we have runC and ccon 21:27:39 ?: what about rkt? 21:27:57 mrunalp: I think rkt will have most of the features, but may not support the API 21:28:10 crosbymichael: there are lots of spec-generating tools, but I think most of them use runC 21:28:23 crosbymichael: there's a lot of low-level code in runC that most people don't care about 21:28:44 mrunalp: I agree with crosbymichael. I don't think we need to wait for more than runC on the Linux side 21:29:19 should we wait until runtime-tools is ready to start stamping certifications? 21:29:29 mrunalp: I'm not sure that is a blocker 21:29:56 RobDolinMS: it hasn't been explicitly stated, but I think the expectation is to have tooling stabilized within a few months of the spec stabilizing 21:30:54 RobDolinMS: if you find issues in the tooling, we may end up with 1.0.1 or 1.0.2 21:31:18 RobDolinMS: The further along the tooling is, the more confidence there will be in the spec's stability 21:31:21 agreed^ 21:31:55 mrunalp: to close this out, we'll look at getting the console and API stuff cut by the end of the month, and then we'll revist stability 21:32:02 sounds good to me^ 21:32:16 RobDolinMS: what's the long pull now? Is it just the console stuff? 21:32:25 mrunalp: yeah. We don't want to break existing consumers 21:32:41 crosbymichael: the concerns are regressions from the console changes 21:33:15 duglin: julz_ works on Garden 21:33:25 crosbymichael: we need to contact him to make sure he's ok with the console changes 21:33:48 mrunalp: crosbymichael, you can check Docker vs. the new console stuff 21:33:53 mrunalp: I'll check kubernetes 21:33:59 #endmeeting