21:02:48 #startmeeting 2017-03-15 discussion 21:02:48 Meeting started Wed Mar 15 21:02:48 2017 UTC. The chair is wking. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:48 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:02:48 The meeting name has been set to '2017_03_15_discussion' 21:02:53 #chair mrunalp vbatts 21:02:53 Current chairs: mrunalp vbatts wking 21:02:58 vbatts, Can you hear me? 21:03:20 okay, I'll dial in. 21:03:35 I think Michael will just speak for RedHat now :-) 21:03:39 [audio trouble with mrunalp] 21:04:28 #topic image issues 21:05:30 stevvooe: we need more design for the image-tools command line API 21:06:13 vbatts: are you envisioning some particular output there? 21:06:35 stevvooe: right now there is progress in a direction, but we don't know if it is the right direction 21:06:48 stevvooe: for example, is using a logger for command output helpful for users? 21:07:10 vbatts: there is some usefulness in being able to toggle verbosity 21:07:24 vbatts: but it's difficult if progress is blocked for a long time waiting on a design 21:07:39 stevvooe: but churn without a design isn't great either 21:08:15 stevvooe: one are is the main use-cases for the command line tool 21:08:34 stevvooe: for example, what's the difference between [...] and unpacking? 21:08:57 stevvooe: with time, I can provide examples (and I have posted a few comments along those lines) 21:09:23 stevvooe: but we need that "what is the input? what is the output?" approach more generally 21:10:17 vbatts: so apart from someone stepping up and doing this in a way that seems suitable... 21:10:23 vbatts: I'm not sure what a best next step is 21:10:48 stevvooe: I'm confused, because this plan of what you're planning on doing and why is part of the usual process 21:11:05 stevvooe: open an issue and say "I'm going to do x, y, z" and we'll say "great, go for it" 21:11:25 vbatts: certification is pushing the tools to cover the MUSTs and SHOULDs in the spec 21:12:08 vbatts: posting details about what was checked with links to the conditions is what we need, and seems to be what is generally happening 21:13:08 vbatts: RobDolinMS had posted a burn-down list of MUSTs/SHOULDs which were tested 21:13:18 stevvooe: where is the doc for how the command line API maps to the cert group? 21:13:30 vbatts: I don't have that, but I'm not on the cert group 21:14:07 vbatts: maybe the work has been done and just hasn't been conveyed well enough? 21:14:35 vbatts: maybe it's a communication issue, and folks are trying to drive progress 21:14:51 stevvooe: folks need to put forward their designs, and then I can help move that forward 21:15:07 stevvooe: but if the response is "here are 4 more PRs", that's not helping with design 21:15:27 [caniszczyk, Open Container Initiative] essentially the CertWG is asking for tooling to help validate the MUST/SHOULDs in the specs (i.e., runtime-tools) https://github.com/opencontainers/runtime-tools/issues/66 21:15:29 vbatts: that's not wrong. But it's hard to find a way forward 21:15:54 stevvooe: I feel bad for dragging image-tools through the mud, but we have to have standards 21:16:00 vbatts: so what's the next step that you see? 21:16:25 https://github.com/opencontainers/image-tools/pull/46#issuecomment-265263029 21:16:39 #link https://github.com/opencontainers/image-spec/issues/467 21:16:56 ^ #467 has been mentioned as a blocker for the image-tools command-line API before 21:18:02 https://github.com/opencontainers/image-spec/issues/588#issuecomment-285480614 21:18:53 vbatts: so we're asking folks for examples like those? 21:19:08 stevvooe: yeah. Speaking in the language of the spec 21:21:15 RobDolinMS: I'd be glad to take a stab at this 21:21:32 vbatts: that sounds good to me 21:21:51 stevvooe: my request was less grandiose; just focused on image-tools 21:22:27 https://github.com/opencontainers/image-tools/issues/96 21:22:39 https://github.com/opencontainers/image-tools/issues/96#issuecomment-286212355 21:22:43 stevvooe: I just want one example of output for a given command, and some discussion of use-cases 21:23:30 https://github.com/opencontainers/image-tools/pull/46#issuecomment-286845711 21:23:52 stevvooe: the trigger for this is "let's just merge it to go forward" doesn't help us figure out where we're going to 21:24:54 RobDolinMS: Is #96 where this discussion should happen, or do we want a new issue for a use-case doc? 21:25:23 stevvooe: I'm fine merging into a single tool, but I think we need to consider the other parts of the API as well 21:25:43 crosbymichael: the testing tools are for the cert working group, right? 21:26:08 RobDolinMS: Yes. We want 'image-tools validate image ...' to test compliance with the spec 21:26:27 crosbymichael: we need that on the runtime side as well. Maybe we need more maintainers in the cert group for communication? 21:27:05 mrunalp: I've been trying to attend them, but only making around 1 of each 2 21:27:13 crosbymichael: can you send a reminder to the TDC? 21:27:28 RobDolinMS: Every other Monday at 10am Pacific 21:27:38 crosbymichael: can you send a notice to the mailing list? 21:28:08 RobDolinMS: Forwarding to dev@ right now... 21:28:32 mrunalp: anything else for images? 21:28:34 vbatts: not now 21:28:46 https://github.com/opencontainers/runtime-spec/pull/405 21:28:47 mrunalp: is Sam on the call? 21:28:47 [caniszczyk, Open Container Initiative] I also encourage the OCI TDC to explore what is going on here https://github.com/opencontainers/certification (we can do our best to use GitHub to communicate instead of via a call always) 21:28:56 #topic VMs in the runtime spec 21:29:28 Sam: I'm not sure what's blocking it. There have been a few review cycles 21:29:48 Sam: I think most of the review has been addressed. There is still a question about structure for the image path 21:30:02 Sam: Is that the only blocker, or are there larger structural issues 21:30:08 mrunalp: does this covers Windows as well? 21:30:14 Sam: I'm not sure 21:30:52 stevvooe: this is saying where the base disk image, right? 21:30:58 Sam: yes, in the guest OS 21:31:16 stevvooe: is it possible to introduce a guest OS image without specifying it in the container config? 21:31:31 stevvooe: and will this work for all VM runtimes? Windows? Hypervisors? 21:31:55 Sam: I don't know about Windows, but this will work for Hyper (another VM-based runtime using ... and KVM) 21:32:03 Sam: They also need an image path 21:32:08 Sam: I'm not sure about Windows 21:32:45 crosbymichael: on the runtime side, why do these have to go in the config and not go in via command-line options, etc.? 21:33:12 Sam: Because it's configurable. We have configs for the runtime, and you can use different guest kernels for different containers with this change 21:33:43 Sam: It's really about the runtime. The container shouldn't care about the guest OS or kernel 21:34:15 Sam: The container image we export in various means from the host to the guest, but it doesn't define the runtime itself 21:34:46 Sam: VM-based containers have a runtime like the current runtime spec, but we also need the kernel and image to start the VM 21:35:11 crosbymichael: how much of the spec is applicable to VMs? I can see process, but what about devices, cgroups, namespaces? 21:35:20 Sam: You can apply cgroups and namespaces inside the VM 21:35:57 Sam: Does it make sense to do that? Sometimes. 21:36:20 Sam: Sometimes the VM is sufficient isolation, but sometimes it might give better security 21:36:39 Sam: For example, we don't want to expose the host network namespace inside the VM 21:37:02 Sam: There are many ways to export devices through a virtual machine. PCI passthrough, etc. 21:37:08 stevvooe: what about mounts? 21:37:21 Sam: We support that, using [...FS] for exports 21:37:46 ^ 9pfs 21:37:54 stevvooe: you couldn't use the mount to supply the root filesystem 21:38:03 Sam: We also use a 9pfs mount for the root filesystem 21:38:11 stevvooe: so why do you need the image path? 21:38:26 Sam: The mount I'm talking about is the container rootfs. The image path is the guest OS 21:38:40 Sam: We're basically creating a container inside the VM 21:38:56 Sam: Think about it as yet another volume mount for the VM 21:39:26 stevvooe: So you boot in the image and then chroot into the mounted rootfs? 21:39:30 Sam: As an example, sure 21:39:58 Sam: The case for having this in the config is that for VM-based containers, this is defining the runtime 21:40:24 Sam: the image spec and kernel pass it directly to KVM/Qemu 21:40:58 Sam: I don't know of any hypervisor that doesn't need a kernel and image path (unless you're using ... to make the image path optional) 21:41:12 stevvooe: thank you for clarifying 21:41:39 Sam: Without this in the spec we need a separate config for the runtime, and we might end up stuck with one kernel and image 21:41:53 Sam: Having it in the runtime config gives us more flexibility 21:42:42 crosbymichael: my concern about having it in the spec is that you have a container runtime that is entirely honored. And then a VM case, where maybe 50% of the settings are valid, but the container works anyway 21:43:21 Sam: There are some settings that we cannot support, but we can support most settings 21:43:38 Sam: Sometimes you might want to block support for policy reasonsr 21:43:57 Sam: If it helps, I can come back with a list of unsupportable settings 21:44:02 mrunalp: that would be helpful 21:44:20 mrunalp: and we can add notes to those settings about how they are handled in VMs 21:44:27 Sam: I can add that to the PR 21:45:14 RobDolinMS: I've pinged some Windows folks to take a look as well 21:45:19 #topic runtime-tool 21:45:42 mrunalp: We have a rough roadmap for runtime-tools 1.0. I'll mail dev@ 21:45:57 mrunalp: One big item is the command line API 21:46:08 https://github.com/opencontainers/runtime-tools/pull/321 21:47:41 mrunalp: the JSON Schema can go in a schema/ directory 21:48:00 mrunalp: anything else? 21:48:45 #topic runtime rc5 support 21:48:53 vbatts|work: where is runC rc5 support? 21:48:59 https://github.com/opencontainers/runc/pull/1370 21:49:07 FINAL 21:49:09 mrunalp: what do you think crosbymichael ? Are we ready for a 1.0 vote? 21:49:34 vbatts|work: a vote lasts a week 21:49:53 crosbymichael: I'd be more comfortable after the runC PR lands and percolates up the stack 21:50:12 vbatts|work: what's the timeline on that cycle? 21:50:45 RobDolinMS: I'd suggest holding off on 1.0 until we've driven down the issues/PRs 21:50:57 mrunalp: there aren't many issues/PRs left 21:51:13 mrunalp: but I agree with crosbymichael that time to cook the runC implementation would be good 21:51:37 RobDolinMS: I think crosbymichael and mrunalp are saying "don't put up the vote, we need more testing" and I think that's good 21:51:54 vbatts|work: if we land runC#1370 and cut a runC 1.0.0 rc3, then... 21:52:01 crosbymichael: cri-o integration 21:52:08 RobDolinMS: rkt? 21:52:13 mrunalp: we can reach out and ask 21:52:59 crosbymichael: a final sanity check would also be good 21:54:04 crosbymichael: I don't think we conveyed that rc5 was the last pre-1.0 RC 21:54:17 crosbymichael: I think we need to get the word out to the wider community for final review 21:54:22 mrunalp: that makes sense 21:54:33 #link https://github.com/opencontainers/runtime-spec/issues/726 21:54:57 Brett: We can kick off that review if someone wants to send an email 21:56:08 vbatts|work: how do we want to organize this? 21:56:16 crosbymichael: mrunalp and I can handle runC 21:56:20 crosbymichael: I'll take the lead on Docker 21:56:32 crosbymichael: and everybody on the final sanity check with all maintainers signing off 21:56:48 crosbymichael: other folks, and the cert team, may also want a final walkthrough 21:57:08 RobDolinMS: I think we want to encourage minor changes in lots of tiny PRs (vs. big batch PRs) 21:57:49 crosbymichael: do we want a timeframe? By next week's meeting? 21:58:48 RobDolinMS: I think we cut rc6 and then start the 30-day member review period 21:59:19 crosbymichael: so our final technical reviews by next week, then we cut our take on the 1.0 21:59:48 RobDolinMS: Walli has been working on compliance testing. His input would be helpful 22:00:09 RobDolinMS: For example, problems with implementations that aren't the reference implementation 22:00:18 crosbymichael: I'll get in contact with him today 22:00:31 crosbymichael: this will be the speak now or forever hold your peace 22:00:44 mrunalp: sounds like a plan. Anything else? 22:00:49 #endmeeting