17:03:54 #startmeeting OCI_July_13 17:03:54 Meeting started Wed Jul 13 17:03:54 2016 UTC. The chair is mrunalp. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:03:54 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:03:54 The meeting name has been set to 'oci_july_13' 17:04:52 mrunalp: chair me? 17:04:58 #chair wking 17:04:58 Current chairs: mrunalp wking 17:05:26 #topic command-line API 17:05:34 #link https://github.com/opencontainers/runtime-spec/pull/511 17:05:36 #link https://github.com/opencontainers/runtime-spec/pull/513 17:05:56 duglin: I'm looking for some review on #511. Are we pushing that approach forward? 17:06:00 mrunalp: I'm ok either way 17:06:20 https://github.com/opencontainers/runtime-spec/pull/513 17:10:31 #408 is a blocker to allow us to collect the collect the container exit code in a portable way (without the Linux-specific subreaper stuff) 17:11:05 julz_: I think we should cut an API spec with exactly what runC has today, and then we can adjust with smaller pivots 17:11:15 mrunalp: and we don't have to cut 1.0 immediately after it lands 17:13:11 if we land the current runC API as 1.0, compliance testing for Windows runtimes may be impossible (how would you collect the container process exit code) 17:13:29 RobDolanMS: Can someone send me these references so we can evaluate Windows compliance 17:14:13 RobDolanMS: We can just add a TODO marker to the PR, so we don't have to put in some stopgap implementation 17:14:59 action wking to ping RobDolanMS about #513 17:15:41 anuthan_: Solaris currently has create/start/delete 17:16:29 which process is waiting on the container process exit code? 17:16:42 anuthan_: On Solaris, 'start' waits on the container process exit 17:17:01 anuthan_: The kernel thinks it's running at 'create' time, but there's no user process until 'start' 17:17:10 duglin: 17:17:36 jlb13: The process that anuthan_'s talking about is a daemon, similar to containerd 17:17:55 jlb13: When you create a Solaris container, it doesn't add another process. The process is launched at 'start' time 17:18:10 jlb13: I believe Windows works similarly 17:18:12 so spec needs to support any model where a process is waiting on the exit 17:19:14 ^ difficult to do ;). 17:19:29 yes, but not difficult to specify 17:20:07 who what how.. isnt a requirement just that the action occurs 17:20:53 isn't a requirement of the cli spec.. 17:21:02 julz_: the --pid approach is the defacto standard 17:21:09 Why do we have --pid instead of calling 'state'? 17:21:22 julz_: I'm not sure, maybe if the process dies before you call 'state'? 17:21:50 julz_: both containerd and Guardian are using --state, but it may not matter 17:22:24 ^ let's not boil the ocean 17:22:24 And we're punting on Windows/Solaris integration? 17:22:32 julz_: yes, for now 17:23:46 jlb13: I don't think it's good to have a platform-specific API spec as a first pass 17:24:09 jlb13: We may have future trip-ups, but we should be able to abstract in the spec 17:26:04 jlb13: I still think there's a terminology hangup here 17:26:29 jlb13: when you create a process on Linux, there's a new process 17:26:35 yes 17:26:39 jlb13: and then at start? 17:27:00 julz_: 'start' tells the process from 'create' to exec the user code, and 'start' immediately exits 17:27:10 jlb13: we do the same thing, but do the fork and exec at 'start' 17:27:39 jlb13: we just have to figure out how to abstract that into the spec 17:27:59 julz_: say I do 'runC start "sleep 24 exit 2"' 17:28:18 julz_: in the spec as it stands, 'runC start' will send a signal and exit immediately 17:28:49 jlb13: I think this is an implementation choice. We'll compare notes, and maybe be able to match the runC approach in Solaris 17:29:21 jlb13: we want to avoid a platform split, and I think we can 17:29:32 julz_: in an ideal world we could avoid this with a 'runC wait' 17:30:39 I think #508 and the 'event' operation are a pretty straightforward solution to this problem 17:30:48 julz_: I don't want so much in the air at one time ;) 17:30:59 event and/or mrunal's hook solns each provide a mechanism to resolve this issue.. but these solns should be discussed after moving forward with a PR without it.. so we can discuss it at length 17:31:04 Yeah, I can reroll #513 to avoid the #508 blocker to get something landable soon 17:32:42 The other blockers in the chain (before #508) decouple from #513 if we punt on #508 17:33:11 action wking to reroll #513 to be closer to the current runC, punting on cross-platform portability for now 17:33:16 #endmeeting