18:00:47 #startmeeting 2015-01-27 discussion 18:00:47 Meeting started Wed Jan 27 18:00:47 2016 UTC. The chair is vbatts|work. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:47 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:00:47 The meeting name has been set to '2015_01_27_discussion' 18:00:52 #chair wking 18:00:52 Current chairs: vbatts|work wking 18:01:24 (someone have the latest video link? the 1771332256 seems to be 404 again D: ) 18:02:17 should be the same as ever, tianon 18:02:46 i'm in the call, can't sort out how to see the actual number. but it's saved in my phone, and is up and running 18:02:54 doh, now it works 18:02:59 cool 18:03:48 echo echo 18:04:22 yup 18:04:27 Good day :) 18:04:48 fist bump 18:05:24 #action duglin rebase ops PR 18:06:22 #link https://github.com/opencontainers/specs/pull/225#issuecomment-172633075 18:07:33 whoa. that was more like echo(echo(echo))). 18:08:03 bah. parser fail. 18:08:29 #info Present: anuthan, crosbymichael, duglin, jlb13, Liangchenye, Mike Brown (mikebrow), Mrunal Patel (mrunal), RobDolinMS, tianon, wking, Vishnu Kannan (vishh) 18:08:45 Doug: I agree with Michael, ... 18:08:57 Doug: Whether someone else can see is up to the environment 18:09:33 Crosby: The spec should at least say, if you create a container you should be able to get state. 18:09:37 Jesse: Agree 18:09:53 Jesse: leave delegated user and superuser as optional 18:10:18 Trevor: What if I'm running a virtual host and launch nested continers using the same runtime? 18:10:24 I don't think we should recurse 18:10:31 into the children 18:10:38 #info Present: Guest (vbatts) 18:11:12 Doug: This isn't just about querying state, it's about other operations 18:11:53 Jesse: I would not be opposed to different operations having different credentials 18:12:03 Crosby: There are many ways to do auth; 18:12:14 Crosby: If you create it, you can get it. 18:12:52 Crosby: If a runtime is smart and can act on nested containters (or some sort of pod level) that's great, but not required 18:13:12 Jesse: What about multi-tenancy 18:13:57 Trevor: Sounds like we're closer than the current PR text 18:14:30 #topic when are pre-start hooks executed? 18:15:02 crosbymichael: possible security concerns 18:15:19 mrunal: we may need pre- and post-mount hooks to work around any pivot-roots 18:15:55 crosbymichael: for more specific, "right before the process is jailed within the rootfs, run the pre-start hooks" 18:16:22 mrunal: after the configured mounts, but before the pivot 18:17:19 what about not having a pivot? 18:17:51 crosbymichael: what's the point without a pivot? You're probably on your own with unspecified behavior if you don't pivot 18:17:52 Crosby: as the user, you get the same functionality out 18:18:14 Vish: but the spec wouldn't restrict? 18:18:19 Mrunal: right 18:18:34 Mruanl: Crosby's proposal would cover most use cases 18:18:45 Trevor: Could someone talk about why it couldn't be further 18:18:59 Mrunal: You would have already established some settings 18:19:32 yea ! split start & create :-) 18:19:34 vishh: this would be easier without hooks 18:19:39 Vish: What if hooks were handled outside? 18:19:55 Mrunal: It would not cover pre-mount and post-mount 18:20:11 also for adding the container process to cgroups 18:20:20 Vish: Can you write-up some examples? 18:20:57 Crosby: If we want hooks to only be on the house side, the hooks would have to know how to do (set?) and (nest?) 18:21:21 Mrunal: that's how it is in runc right now 18:21:30 Mrunal: it gives the most flexibility 18:21:44 Mrunal: Example: having hooks write before and after container mounts are done 18:22:20 Mrunal: After the pivot, you don't have access to the host mounts 18:22:50 Vish: Can we come-up with an example case that doesn't work? 18:22:50 vishh: wants a case where mount propogation wouldn't work 18:23:00 vishh: the less we do, the more flexible the whole design will be 18:23:15 #Action: Mrunal post example case that doesn't work 18:23:41 Vish: Hooks are awesome, we're just going to make it awesomeer 18:24:01 ( ^ one line summary of the meeting :) ) 18:24:17 vishh: instead of adding more hooks, just make a sandbox and let the user do whatever they want to the sandbox before launching a process in the sandbox 18:24:40 #topic JSON Schema validation 18:24:41 #topic JSON Schema 18:24:58 #link https://github.com/opencontainers/specs/pull/313 18:25:01 Vincent: It's getting closer 18:26:02 Vincent: It's pretty good; interger ranges can be specified 18:26:31 Vincent: I have not seen tooling on generating a sample JSON document from a schema 18:27:02 Vincent: Could be built into OCI validation tooling 18:27:40 Vincent: Could be self-versioned or could have schema that validates the released version 18:28:00 Mrunal: How well does it handle the optional fields? 18:28:11 Vincent: Pointers are a challenge 18:28:58 Vincent: Everything is implied optional; can add to indicate required 18:29:36 Vincent: The Linux field in the config file references out to a LinuxSchema.json 18:30:05 Vincent: May be a bit complex to have some fields required and some not based on different platforms 18:30:21 Mrunal: I'll take a look from a runc perspective 18:31:05 Trevor: There are lots of validators, if one doesn't work, we can replace 18:31:37 Vish: Are you using Swaggr? 18:31:49 aka wsdl :-) 18:32:06 #link https://openapis.org/ 18:32:25 Vincent: It's largely a forward dialect of JSON Schema 18:32:37 Vincent: There is additional markup to accomodate XML and YAML 18:33:54 Vincent: Moving to OAI / Swagger is not blocked by starting with JSON Schema 18:34:26 #action Vincent to continue iterating 18:34:33 #topic Create and Start 18:34:48 #info Doug has a PR and would like someone to take a look 18:34:57 #action vishh to take a look at PR 18:35:07 #topic Issues for v0.4 18:35:25 vishh the PR is on runc 18:35:31 ack 18:35:51 Call for "release captain" 18:36:02 #action Mrunal will start a thread about v0.4 issues 18:36:18 #EndMeeting 18:36:43 Post meeting chat discussion… https://github.com/opencontainers/runc/pull/507 18:36:43 Should the runc list command be true to the stored state on disk or should it refresh state on those containers 18:36:43 to make sure check the state at the point of reporting it is correct. Then if refresh is the choice we pick 18:36:45 should we report or have the option of reporting the differences? 18:37:16 mikebrow: just go by what the container.State() returns 18:37:25 if changes are needed we will make them to that api 18:37:27 not in runc 18:37:44 (Did we have MeetBot running for the minutes? ) 18:37:46 makes sense 18:38:16 Thx @crosbymichael 18:38:25 RobDolinMS: yeah, although I don't think you were ever added as #chair 18:38:37 ping vbatts|work 18:38:43 (to end the meeting) 18:39:03 #endmeeting