17:00:47 #startmeeting 2016-05-04 discussion 17:00:47 Meeting started Wed May 4 17:00:47 2016 UTC. The chair is vbatts. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:47 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:47 The meeting name has been set to '2016_05_04_discussion' 17:03:02 wking: was that you? 17:03:11 vbatts: #chair me? 17:03:16 #chair wking 17:03:16 Current chairs: vbatts wking 17:03:28 #topic reviewing open PRs 17:03:40 https://github.com/opencontainers/runtime-spec/pull/411 17:04:03 mrunalp: what's left to do here? 17:04:45 Abhijeeth: nothing that I know of 17:04:57 crosbymichael: are we ok with hyphenated keys instead of camelCase? 17:05:15 Abhijeeth: we want to keep the names the same, because they've been that way for a very long time 17:05:48 anuthan_work: is Abhijeeth 17:06:48 vbatts: it's good to have both spec consistency and consistency with the OS. For Linux, most keys are runtime-specific, and don't map directly to the runtime (which gives you a bit of indirection to protect from kernel churn) 17:08:01 jlb13: We'll take whatever the advice is. For Solaris users, it's easier not to change. But it doesn't take a rocket scientist to map between hyphens and camelCase 17:08:24 we were assuming it was platform specific and that nobody would care, but we're ok switching 17:08:59 vbatts: also, feel free to decode in the comments 17:09:11 jlb13: probably not worth it, since it's not a big leap. 17:09:50 jlb13: we're not super passionate about this (lots of internal bikeshedding, we started with camelCase, we'll just take it back inside and blame it on the OCI) 17:10:03 https://github.com/opencontainers/runtime-spec/milestones 17:10:13 mrunalp: do we want to cut 0.6? 17:10:20 gah no one can hear me 17:10:32 I do want to discuss solaris + networking for a sec 17:10:33 vbatts: no date or issues on the current 0.6 milestone 17:11:05 vbatts: there's also a 1.0-rc that's parked as well 17:12:01 philips: going back to Solaris, is networking tied to the container lifecycle (it's not for Linux) 17:12:12 And adding subnet configurations and such is a first for this spec 17:12:35 anuthan_work: it is, because we put it up at setup time and tear it down when the container dies 17:12:45 philips: is the lifecycle tied to a particular process? 17:13:08 anuthan_work: no. There's a daemon which takes care of the container and maintains it's state 17:13:31 philips: so essentially an init process that owns the lifecycle. Do you talk to that process to, say, launch a second process inside the container? 17:13:53 anuthan_work: we have a separate mechanism (through the kernel) to add processes 17:14:25 philips: probably worth adding a note to say that the network needs to be setup for the first process in a container, so it's clear to non-Solaris folks that that's a requirement 17:14:48 philips: the lifecycle of the networking + process, or a link to the upstream docs, or something 17:14:51 anuthan_work: we can do that 17:15:04 mrunalp: anything else for Solaris 17:15:05 ? 17:15:23 mrunalp: I tagged #411 for 0.6.0 17:15:32 https://github.com/opencontainers/runtime-spec/pull/417 17:16:11 mrunalp: in the past we suggested explicitness instead of specifying defauls 17:16:21 mrunalp: is that still the case? If so, we can close this 17:16:38 crosbymichael: in the spec it says uid is required anyway 17:16:52 philips: yeah, it should be required 17:17:13 https://github.com/opencontainers/runtime-spec/pull/415 17:18:02 I have to step out for one sec ;) 17:18:25 lgtm 17:19:06 https://github.com/opencontainers/runtime-spec/pull/405 17:19:56 https://github.com/opencontainers/runtime-spec/pull/397 17:19:56 I'm back 17:20:03 mrunalp: what about the cgroups namespace PR 17:20:17 philips: probably worth waiting for the first stable release 17:20:24 * kernel release 17:20:42 https://github.com/opencontainers/runtime-spec/pull/412/files 17:22:57 lolz 17:23:14 https://github.com/opencontainers/runtime-spec/pull/384 17:23:21 #action wking to reroll #412 with more clarification 17:24:17 duglin: I tabled that after last week's confusing discussion 17:25:17 vishh: my understanding after last week was that we needed external changes first before pushing stuff into the repo 17:27:11 vishh: I thought last week there was talk about pushing changes into ocitools? 17:27:46 julz_: avoiding hooks is still a good thing to do 17:28:08 julz_: it doesn't need to pull in bind mounts 17:28:18 vishh: I don't want to drag in post-stop hooks here 17:28:20 julz_: agreed 17:28:39 vishh: it depends on whether we want to capture a majority of use cases or be a thin kernel wrapper 17:29:00 vishh: we want portable post-stop hooks 17:29:33 vishh: to make progress, it seems like we want to split create/start 17:29:51 julz_: some things are ugly to achieve via the current hooks 17:30:14 crosbymichael: you can make your namespaces ahead of time 17:30:35 julz_: yes for the network (which may pull in user namespaces). 17:31:08 mrunalp: there's currently no network config in the spec anyway 17:31:55 julz_: yeah, and I think that's good. I'd just rather invert control and allow the caller to control the current-hook functionality directly (instead of calling by proxy through the runtime) 17:32:39 julz_: we should admit that this is a spec for orchestrators, and it's easier for an orchestrator to drive tools directly (vs. through hooks) 17:33:14 julz_: and there's no reason to drop the current 'run' (or whatever) that bundles all of this together and keeps hooks 17:33:28 duglin: and that's what the PR has now 17:33:58 mrunalp: I'm ok with doing that 17:34:34 vishh: turning it around, any objections? 17:34:58 philips: no objections yet. I have questions about the implementation, but I guess that's in runC 17:35:19 crosbymichael: lets not land the spec until we know it's possible 17:35:47 mrunalp: so we all agree that we want to land this in a runC branch 17:36:10 vishh: I'd like a list of use cases 17:36:26 I'd posted some in my 3-proposal comparison^ 17:36:38 mrunalp: by 1.0? 17:36:48 duglin: yes please 17:37:32 philips: can we get a high-level description of what's going on in the runC PR? 17:37:49 philips: who does what, when? 17:38:11 #action duglin to write a high level explanation 17:39:36 duglin: although the current runC PR doesn't have start-time PID creation 17:40:29 duglin: this is getting into the 'exec' conversation 17:40:42 vishh: 'exec' is one word with many use cases, but for post-stop it's very clear 17:41:04 duglin: I understand that splitting stop/delete lets you put in post-stop hooks 17:41:23 duglin: but the sub-container approach to pinning namespaces is similar to 'exec' 17:41:43 vishh: I think sub-containers are fragile and expose too many low-level details 17:42:00 vishh: so I think we want to continue exploring post-stop hooks and/or a stop/delete split 17:42:23 julz_: it would be sad to invent a second way of doing things just because we moved 'exec' from the spec 17:42:38 julz_: if sub-containers are fragile, that's a big problem in its own right 17:43:03 julz_: I think it was right to pull it out of the spec, because using config.json to do exec-like things is good 17:43:13 julz_: but pulling it out and ignoring those use cases is not good 17:43:46 julz_: there's no agreement on what's in the sandbox or what's getting joined. But we should make it easy to join the sandbox parts you want 17:44:05 vishh: I think you're conflating runC with other implementations (e.g. a long-running init process) 17:44:24 vishh: if you look at it from a semantic level, the 'exec' use case is very different from hooks 17:44:58 julz_: thinking about it that way is another reason to hesitate about hooks. Solaris folks have a daemon, can they do bind-mount-like preservation? 17:45:11 vishh: we don't have much non-Linux information, maybe focus on that? 17:45:19 julz_: yeah, and we know sub-containers work there 17:45:36 vishh: maybe a generic utility that talks over a socket to your process, and you don't need a single binary 17:45:55 vishh: pushing everything up into higher levels defeats the purpose of the spec 17:46:12 julz_: I don't think I'm saying that. I'm saying we should have an expressive spec that makes sub-containers easy 17:46:33 julz_: once you have that, you can pin namespaces with sub-containers, so why add a separate namespace-binding requirement? 17:46:54 vishh: I'd rather think about portable post-stop hooks, and then move on to consider exec 17:47:10 julz_: I agree with the distraction, and they're kind of orthogonal 17:47:18 mrunalp: we can make them optional 17:47:49 wking: are you still a compliant runtime if you don't support post-stop hooks 17:48:00 mrunalp: I mean optional in the config 17:48:27 julz_: the fundamental problem I've had with post-stop hooks is that it's hard to opt out 17:49:02 mrunalp: maybe you'd only require an explicit 'destroy' if the config had post-stop hooks 17:49:55 vishh: but if the foundational layer can split stop and delete, you can just immediately invoke delete after stop 17:51:40 duglin: the PR for the spec side of this splits create/start (with a merged 'run'). And you have a single 'delete' if that's what you want 17:51:55 julz_: but it still requires you to call 'delete' 17:52:09 julz_: now namespaces just clean up themselves (with kernel reaping) 17:52:19 duglin: you could do that with a flag... 17:52:39 julz_: that was what mrunalp was saying. You'd have to set it up at create-time, and that's fine 17:53:00 julz_: but in order to pin a namespace, you need to know what namespaces you want to pin 17:53:13 julz_: that's the same "what namespaces?" issue we have with 'exec' 17:53:46 julz_: I certainly think experimenting is fine, but having two spec ways to do one thing seems like a shame 17:54:08 duglin: so if I go back to the spec PR and add a "PID 1 kills everything" flag, which opts you out of the stop/delete split 17:54:32 duglin: I'd rather get agreement on the spec PR first, because I don't want to write code that gets thrown out for doing the wrong thing 17:54:56 mrunalp: sounds good to me 17:55:03 vishh: forward progress is good 17:55:21 #action duglin to reroll create/start to make for-delete namespace pinning optional 17:55:34 #topic DockerCon face-to-face? 17:55:44 duglin: some things are easier to resolve face to face 17:56:01 mrunalp: I'll be there 17:56:16 vishh: I hadn't planned to go, but I can make a meeting 17:56:21 crosbymichael: I'll be there 17:56:43 mrunalp: a couple hours is probably fine 17:57:00 philips: I was going to poll for an image meeting in June 17:57:13 philips: images have more international folks, and some aren't on this call 17:57:26 #action duglin to look for a half-day room 17:57:48 #topic splitting create/start 17:58:00 are these in 1.0? 0.6? 17:58:09 philips: it sounds like there is too much in the air 17:58:10 byes! 17:58:12 mrunalp: ok, punt for now 17:58:18 #endmeeting