22:02:53 #startmeeting 2017-02-22 discussion 22:02:53 Meeting started Wed Feb 22 22:02:53 2017 UTC. The chair is wking. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:02:53 Useful Commands: #action #agreed #help #info #idea #link #topic. 22:02:53 The meeting name has been set to '2017_02_22_discussion' 22:02:57 mrunalp: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 22:02:57 #chair mrunalp vbatts 22:02:57 Current chairs: mrunalp vbatts wking 22:03:12 #topic runtime-spec issues 22:03:16 https://github.com/opencontainers/runtime-spec/pull/675 22:03:25 mrunalp: that^ needs only one more LGTM 22:03:44 crosbymichael: and for seccomp, revising the format looks good 22:03:53 crosbymichael: the other thing is just a nit 22:04:03 https://github.com/opencontainers/runtime-spec/pull/657 22:04:20 mrunalp: I'll ping grantseltzer (he'll be back tomorrow) on the nit 22:04:26 brt 22:04:35 mrunalp: should we close PRs where we check kernel limits? 22:04:43 https://github.com/opencontainers/runtime-spec/pull/533 22:04:50 crosbymichael: I think so, otherwise it's a lot of maintenance overhead to stay current 22:05:00 https://github.com/opencontainers/runtime-spec/pull/689 22:05:40 #link https://github.com/opencontainers/runtime-spec/pull/693 22:05:48 this sounds like the direction we want to head in^ 22:06:29 #link https://github.com/opencontainers/runtime-spec/pull/690 22:07:29 I think you have to document either the valid values, or the kernel API you're punting to 22:07:49 mrunalp: do we have a reference to the kernel's device cgroup in the doc? 22:07:56 crosbymichael: yeah, that sounds fine 22:08:26 mrunalp: I'll check to see what we have in terms of referencing kernel APIs 22:08:40 mrunalp: anything else for 1.0? 22:08:56 https://github.com/opencontainers/runtime-spec/issues/692 22:09:42 mrunalp: I guess we can use -1 for unlimited? 22:09:50 crosbymichael: isn't that what we have now? 22:09:59 mrunalp: yeah, but we'll have to drop the current unsigned types 22:10:16 crosbymichael: this is because rlimits are inherited? So you need a way to unset them? 22:10:46 mrunalp: otherwise there is no way to express "set the rlimit to infinity" 22:10:53 crosbymichael: what's the value of infinity? 22:12:57 they are inherited through fork (says prlimit(2)), so infinity lets you clear limits inherited from the runtime when creating the container process 22:13:08 crosbymichael: we can use -1 for this in the spec 22:14:08 hqhq: we'll need to pass RLIM_INFINITY to the kernel 22:14:25 mrunalp: yeah, so -1 in JSON and then pass whatever the kernel needs through to it 22:14:41 crosbymichael: RLIM_INFINITY may already be defined in the syscall package 22:14:59 crosbymichael: we can use that in Go^ 22:15:13 crosbymichael: Go's syscall platform defines that for every platform 22:15:23 mrunalp: what would the JSON look like? 22:15:53 mrunalp: they'd lookup their local RLIM_INFINITY and put that value into the JSON 22:16:00 ^ that was crosbymichael 22:16:08 mrunalp: or do we define those as strings? 22:17:04 crosbymichael: yeah, it's a string 22:17:04 https://github.com/opencontainers/runc/blob/ed2df2906b7ec5c69897d5539ab85371b8ae7776/rlimit_linux.go 22:18:13 # define RLIM_INFINITY (~0UL) 22:18:23 ^ from uapi/asm-generic/resource.h in the kernel 22:18:50 #link https://github.com/opencontainers/runtime-spec/issues/663 22:19:16 it sounds like the plan is to punt here, but nobody has punted it yet ;) 22:19:43 mrunalp: I think it may be worth keeping in the spec, so there's only one place to look to find the container state 22:19:50 crosbymichael: I'm fine either way 22:20:03 so we're closing the issue? 22:20:12 crosbymichael: yeah. I can live with it 22:20:25 mrunalp: anything else? 22:20:37 mrunalp: crosbymichael, once we cut the final RC, we'll have a cooking period? 22:20:53 crosbymichael: yeah. We'll have to implement it in runC and then see how well runC consumers handle it 22:21:18 mrunalp: so cut a new RC after the issues discussed above, and then a 3 or 4 week cooking period? 22:21:24 crosbymichael: yeah 22:21:45 mrunalp: on a related note, I'd like runtime-tools feedback 22:22:17 mrunalp: currently runtime testing creates a busybox rootfs, create a config, launch a container with a test process, and the test process decides if the container matches the config 22:22:33 mrunalp: going forward, we want to do this with multiple configs to cover multiple runtime environments 22:22:53 mrunalp: we could have a suite of configs, and maybe different root filesystems 22:23:30 mrunalp: there's another school of thought to do something like HTML validation, where you go through the suite and test each requirement mostly independetly 22:23:46 mrunalp: do we want to be able to map failures back to specific requirements or not? 22:24:07 stephenrwalli: it sounds like you're saying two things... one sounded output specific, and another sounded like a coverage issue 22:24:25 stephenrwalli: RobDolinMS and myself have been concerned about output as a means towards the coverage end 22:25:00 stephenrwalli: so someone looking at the test results should have a sense of coverage and guidelines for what failed and what we can fix 22:25:13 mrunalp: today if you look at the output, you can see 16 sections that passed 22:25:36 mrunalp: if we go forward with multiple configs, we'll be checking rlimits (or whatever) many, many times 22:25:53 mikebrow: I recommend dumping it out and putting a summary at the end 22:25:59 stephenrwalli: I'm a fan of verbose output 22:27:05 I think TAP harnesses make this easy 22:27:34 mrunalp: with a Go test harness (which is easy to run) we can make the output whatever we want 22:27:50 mrunalp: this is the runtime-tools runtime validation 22:28:25 crosbymichael: for aggregation, could you have a generic rootfs that you reuse. Mount that readonly, and provide your config on stdin, and then push JSON test results out stdout? 22:28:32 crosbymichael: then generate a report at the end? 22:28:44 mrunalp: that's what I had in mind, aggregating across all the runs 22:28:54 mrunalp: it will take more work, but it would be possible 22:29:24 stephenrwalli: do the runtime-tools instructions cover how newcomers should run this suite? 22:29:30 mrunalp: there's an in-flight PR for that 22:29:45 crosbymichael: structured output is easier to use 22:29:56 @mrunalp Do you know the PR? 22:29:56 stephenrwalli: Error: "mrunalp" is not a valid command. 22:31:01 mrunalp Do you know the PR? 22:31:09 mrunalp: lifecycle tests will have to be separate 22:31:26 crosbymichael: I think we have three tests: config validation, runtime validation, and lifecycle validation 22:31:59 mrunalp: does anyone have an opinion on testing frameworks? I don't really mind 22:32:17 crosbymichael: I don't mind. I think the end result should be a report, so callers don't need to know about a particular testing framework 22:32:37 stevvooe: my general recommendation is to not get mired in the output format 22:33:01 stevvooe: you can re-exec Go tests as you see fit in a compiled binary, parse the output, and convert to other types of testing formats 22:33:02 When we’re talking about Go test framework, we aren’t talking Go’s _test work — correct? 22:33:16 stevvooe: but the idea is to make test addition very lightweight for existing Go developers 22:33:44 stephenrwalli: something that gives us a pass/fail with a count is all I think the certification working group needs 22:33:57 stephenrwalli: but it should be easy to re-create the certification experiment on your own 22:34:18 * vbatts watches from afar for just a moment 22:34:30 stevvooe: I think Go's testing will avoid lots of bikeshedding over TAP vs. XUnit, vs. 22:34:40 stevvooe: we can always convert the output format later if we want 22:35:04 #link https://github.com/opencontainers/runtime-tools/pull/326 22:35:29 stevvooe: a testing framework has typically already thought through problems of consumption 22:35:45 stevvooe: if we completly roll our own we might get something wrong 22:35:54 mrunalp: I think that's it for the runtime 22:35:58 #topic image-spec issues 22:36:07 stevvooe: without vbatts there's not much to discuss 22:36:22 stevvooe: looks like the rc5 vote passed 22:36:41 stevvooe: I'm in the process of consuming the image-spec now, so I'll be able to provide more feedback soon 22:37:01 stevvooe: cyphar is now an image-tools maintainer, so that project should get polishing soon 22:37:15 stevvooe: does anyone else have specific image topics to discuss? 22:37:29 the vote needs the PR to get LGTM'ed! 22:37:32 wking: ^^ 22:37:35 jbouzane: I don't have anything I wanted to discuss 22:37:49 can someone speak this :-) 22:38:12 https://github.com/opencontainers/image-spec/pull/566 22:39:07 #endmeeting