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