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