22:00:09 #startmeeting 2017-02-08 discussion 22:00:09 Meeting started Wed Feb 8 22:00:09 2017 UTC. The chair is vbatts. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic. 22:00:09 The meeting name has been set to '2017_02_08_discussion' 22:00:35 that filled up fast :D 22:00:43 [caniszczyk, Open Container Initiative] vbatts: https://www.youtube.com/watch?v=zh9h4KZpnJU 22:01:25 crosbymichael, cyphar, hqhq, vishh: Joining? 22:01:29 wking ^ 22:01:35 vbatts, mrunalp: I can't take notes yet, but I should be listening in shortly 22:01:41 cracra: nooo, that's evil 22:02:57 wking: thanks 22:02:58 [caniszczyk, Open Container Initiative] https://github.com/opencontainers/tob/issues/27 22:03:11 #chair wking mrunalp 22:03:11 Current chairs: mrunalp vbatts wking 22:03:25 #topic New repo for go-selinux 22:05:00 cracra to help with the process 22:05:14 vbatts, PR open for renaming a manifest 22:07:22 #topic CLI API 22:07:29 should we block on other platforms? 22:07:40 how to handle console-socket on Windows? 22:09:01 #link https://github.com/opencontainers/runtime-spec/pull/513/files 22:09:07 I'd guess the current console-socket stuff is not portable to Windows, and they'd need a different approach 22:09:27 Yes 22:09:33 I'm not aware of any compliance-testing work on Windows, so I'm not sure how much time we want to sink into it 22:10:27 mrunalp: RobDolinMS, can you get back to us soonish on how this would work on Windows? 22:10:42 vbatts: or on whether it's already clearly-enough scoped to POSIX systems 22:11:27 I'm also happy to drop in a "the following only applies to Linux/Solaris", just tell me where to put it 22:11:41 jlbutler: I expect this to work on Solaris, but have trouble on Windows 22:11:59 jlbutler: But I'm wondering if this should be more abstracted (with platform-specific sections in the config?) 22:12:10 jlbutler: there's a boundary between a spec and a design document 22:12:34 jlbutler: this PR has been going around forever, and I brought this up at a face-to-face (8 months ago?) 22:12:49 mikebrow_: that's valid, and there are "for examples" in other Linux stuff 22:13:12 jlbutler: I think it's doable because there are mostly POSIX systems and Windows, so that's not too many 22:13:28 jlbutler: so Solaris is covered, no problem 22:14:13 In the interest of moving forward, I think we should just rule out Windows wherever we need to, land #513, and address Windows in a follow-up PR 22:15:09 stevvooe: what is the goal of defining a CLI? 22:15:20 mrunalp: it's for compliance testing 22:15:36 mikebrow_: and you can have more runtime interfaces than just this 22:15:49 mrunalp: this is the simplest way to get generic compliance testing 22:16:04 stevvooe: if you overspecify, you might limit possible interfaces 22:16:36 you can add additional interfaces 22:16:50 mikebrow_: this allows you to replace runC with runB (or whatever) 22:17:06 mrunalp: yeah, and this allows consumers to avoid chasing runC (unless they want to) 22:17:14 mrunalp: I don't see a lot of further evolution on the runtime side 22:17:41 stevvooe: let's take Git as an example. They separate the UX (pull, merge, ...) from the low-level plumbing 22:18:00 stevvooe: with runC, you'd be binding the UX to a spec. But what we want is consistent behavior 22:18:14 stevvooe: you might have different binaries with different UXes 22:20:15 crosbymichael: why not spec a harness 22:20:38 That's what this is. It could be Go, or whatever, but the CLI seems like the lowest common denom harness 22:20:51 crosbymichael: a harness is different 22:20:57 What does a harness look like 22:21:03 stevvooe: Git's plumbing 22:22:04 I am all in favor of making this plumbing like, just let me know what to simplify 22:23:09 RobDolinMS: I'm reaching out to John Starks, ..., and Taylor Brown to look this over 22:23:30 RobDolinMS: Who else should folks contact with questions? 22:23:40 mrunalp: just leave a comment in the PR so everyone can be involved 22:23:52 mikebrow_: folks can call me too if they want 22:24:15 mikebrow_: we already have a section saying that this API is one of potentially several APIs 22:24:30 #link https://github.com/opencontainers/runtime-spec/pull/513/files#diff-0c1e5a5baa5649945697a530e09acbf5R4 22:24:48 connecting from a different client 22:25:01 RobDolinMS: If I undestand right, runtimes must support this harness for compliance testing 22:25:07 #chair vbatts|mobile 22:25:07 Current chairs: mrunalp vbatts vbatts|mobile wking 22:25:22 mikebrow_: yeah. You can have other APIs, but you need the CLI for compliance testing 22:26:14 stevvooe: What if instead of "this is the runC UX", how about "here are the commands you will run in a test harness" with "and here are the results we expect" 22:26:28 stevvooe: then it's more clearly bound to the test harness 22:26:35 mrunalp: isn't this already that? 22:27:12 RobDolinMS: if this is the minimum compliance-testing API, does it belong in runtime-tools? 22:27:41 mikebrow_: that's come up a few times over the past year ;) 22:28:09 RobDolinMS: Are we specifying the set of test cases instead of a command line interfaces? 22:28:20 https://github.com/opencontainers/runtime-spec/pull/513/files#diff-958e7270f96f5407d7d980f500805b1bR12 22:30:07 stevvooe: why not just write the test cases? 22:30:20 mrunalp: in cri-o, we can support multiple runtimes because they use the same CLI API 22:30:59 jlbutler: one of the impetuses for the CLI spec is that containerd couldn't talk to runV 22:31:12 jlbutler: if runC is a defacto standard, what is the point of having a spec? 22:31:47 jlbutler: the runtime has an interface, with actions and verbs, etc. But without a consistent API (e.g. start with 'jump'), it's hard to swap runtimes 22:32:19 jlbutler: the current spec has a lot of detail, which may not be neccessary. And the CLI spec may not need to be in runtime-spec. But this work may still be neccessary 22:33:03 jlbutler: I'm fine with specifying a harness instead of an interface (e.g "what if you have a GUI or web harness?") 22:33:21 jlbutler: I'm concerned that the current #513 is overly restrictive, and folks will skip it instead of implementing it 22:34:04 "When using a container to drop privileges, note that providing a privileged terminal's file descriptor may allow the container to [execute privileged operations via `TIOCSTI`][TIOCSTI-security] or other [TTY ioctls][tty_ioctl.4]." 22:34:26 I'm fine striking things that folks think are too specific, just tell me what we can drop 22:35:30 I'm fine dropping that^^ line (which I'd added on @cyphar's request) 22:35:36 https://github.com/opencontainers/runtime-spec/pull/513/files#r100181851 22:36:02 stevvooe: we want the minimum spec here, it should be up to the spec writer to do that 22:36:15 I'm just trying to make reviewers happy ;). Tell me what to do :p 22:36:38 RobDolinMS: It's clear that a lot of good effort has gone into this 22:36:46 np 22:37:21 mikebrow_: so does this stay in runtime-spec? 22:37:52 I don't care where it lives 22:38:04 crosbymichael: we already specify actions. So I think a CLI spec is overly burdensome 22:38:28 crosbymichael: yeah, we need an agreed interface between runtimes, but I don't think you can specify a CLI and be successful 22:38:56 so you just want outside runtime-spec? 22:40:36 https://github.com/opencontainers/runtime-spec/pull/513/files#diff-958e7270f96f5407d7d980f500805b1bR8 22:40:52 crosbymichael: who is in charge of compliance? 22:41:30 RobDolinMS: A subset of the trademark group. Me, jlbutler, Walli, cracra, sometimes Alex or Janessa from CoreOS 22:42:11 RobDolinMS: There's a very rought draft on .. [URL] 22:42:36 jlbutler: you don't need the API for compliance testing. I don't see why we couldn't test compliance around the existing lifecycle operations 22:42:55 crosbymichael: you can have a different harness for each runtime 22:43:19 crosbymichael: then we don't qualify OCI compliance 22:43:26 Who writes the harness? 22:43:30 crosbymichael: the runtime authors 22:44:14 Then that's what I'm aiming for here. Just tell me what to change 22:44:19 crosbymichael: move it out of runtime-spec 22:46:22 You could write a runtime that is runtime-spec compliant, but without an API spec, there's no way to test your runtime 22:46:33 crosbymichael: so the runtime author writes a harness 22:46:45 crosbymichael: you submit your harness and runtime and get badged 22:48:04 ^ that means that either runtime-tools needs support for a new API or the badged runtime needs to support this command line API 22:48:31 If this gets pulled out of runtime-spec, I think it should get its own repo because it should turn over more slowly than runtime-tools 22:49:30 RobDolinMS: Do we need anything from here in the spec itself? 22:49:39 RobDolimMS: This is not very big 22:49:58 RobDolinMS: Theres a concern about overspecification (particularly around sockets) 22:50:06 mikebrow_: yeah, and sockets were recently added 22:50:31 RobDolinMS: So for next actions: Windows folks to look into this. Everyone to review for over-specifications 22:51:07 RobDolinMS: And then we'll figure out how to split this up between runtime-spec, runtime-tools, and a harness 22:52:11 mikebrow_: if this is moving to a harness spec in tools, then this is sort of moot (we can cut v1 without it) 22:52:22 RobDolinMS: Do we need this besides for testing? 22:52:38 mrunalp: as jlbutler pointed out earlier, containerd expects a particular CLI 22:53:06 jlbutler: the runtime spec lists operations, and describes what the operations do (already in master) 22:53:35 jlbutler: this goes beyond to define a way to call those. I think that's useful, but don't want to see it in the spec 22:53:56 mikebrow_: If it makes more sense to argue this out in a harness repo, we'll do it over there 22:54:30 https://github.com/opencontainers/runtime-spec/pull/513#r72866653 22:54:56 ^ mrunalp asking to keep this in runtime-spec (which is why we didn't split it into its own repo in July) 22:56:13 Everyone agrees to move it out of runtime-spec 22:56:17 Where is it going? 22:56:19 crosbymichael: runtime-tools 22:56:30 crosbymichael: any compliance testers who need help, let me know 22:56:55 mrunalp: runtime-tools needs help 22:57:03 crosbymichael: I'll start helping in runtime-tools 22:57:13 mrunalp: many of the PRs are stuck on one LGTM 22:58:03 mrunalp, can you give me some advice for wedging this into runtime-tools? 22:58:07 mrunalp: will do 22:58:18 mrunalp: anything else? 22:58:45 #topic Open source leadership summit 22:58:49 RobDolinMS: Will a good amount of us be there? 22:58:52 [lots of nos] 22:59:07 RobDolinMS: Should I ping cracra and ask for more invites? 22:59:18 vbatts: I'm sure there will be another face to face soon 23:00:09 RobDolinMS: A week after is Container World. vbatts, you're on a panel? 23:00:23 vbatts: I'll be in late Wed, and then heading out on Thursday afternoon 23:00:37 vbatts: so I'll be there, but there's not much time for OCI stuff 23:00:52 vbatts: There's an open thread on dev@ if folks want to chime in 23:01:16 #endmeeting