18:01:28 <vbatts> #startmeeting 2015-12-2 discussion
18:01:28 <collabot> Meeting started Wed Dec  2 18:01:28 2015 UTC.  The chair is vbatts. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:28 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:28 <collabot> The meeting name has been set to '2015_12_2_discussion'
18:02:06 <mrunalp> crosbymichael: lk4d4: dqminh: philips: tianon: Joining?
18:02:30 <duglin> I’m at the airport so going to try to keep talking to a minimum
18:02:39 <mrunalp> duglin: okay, no worries
18:03:43 <mrunalp> #topic state location
18:04:02 <wking> https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/q6TYqVZOcX8
18:04:16 <wking> #info List thread: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/q6TYqVZOcX8
18:05:30 <wking> #info Command line API thread: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/BIxya5eSNLo
18:07:29 <duglin> IMO it all comes down to what level of interop we’re supposed to define - if none then our value decreases
18:10:17 <wking> jlb13 and vbatts suggesting a command-line API (or whatever, could be REST) spec associated with a lifecycle spec
18:10:56 <wking> vbatts prefers REST to a command-line API spec
18:11:10 <duglin> we could do a rest api but then are we really signing up to define an entire http server?
18:11:22 <wking> julz concerned about performance over REST
18:11:33 <wking> I'm not sure how terminal-binding would work over REST
18:11:40 <lk4d4> I think sh <-> http mapping is pretty straightforward
18:12:22 <mrunalp> lk4d4: yeah, agree
18:12:40 <duglin> if we don’t do a REST APIs and we don’t do a cmd, what other option is there? All I can think of is the filesystem like we do today
18:13:03 <lk4d4> so, I think "actions" discussion is more valuable for spec :)
18:13:13 <wking> mrunalp: provide the minimal command-line API for testing, and then you're free to provide other APIs as you see fit
18:13:19 <duglin> lk4d4: sure but how are those actions exposed?
18:13:54 <vbatts> #chairs mrunalp wking RobDolinMS
18:13:58 <vbatts> #chair mrunalp wking RobDolinMS
18:13:58 <collabot> Current chairs: RobDolinMS mrunalp vbatts wking
18:14:00 <lk4d4> duglin: whatever way you desire I think, but if you want to be replaceable with runc - you have no choice :)
18:14:12 <mrunalp> duglin: Yeah, it is abstract but testing needs more concrete inputs
18:14:21 <wking> mrunalp: maybe base command-line API work on duglin's actions: https://github.com/opencontainers/specs/pull/225
18:14:43 <mikebrow> abstract spec with a compliant implementation example
18:15:02 <mrunalp> mikebrow: That is runc in a way but others just have to copy it
18:15:29 <duglin> not sure I understand what “minimal cmd-line API for testing” really is because it sure sounds like we’re defining a cmd line just trying to avoid calling it that.
18:15:54 <lk4d4> duglin: I agree :)
18:16:01 <lk4d4> it's cli or not
18:16:05 <duglin> yup
18:16:10 <julz> ^ yup
18:16:14 <wking> duglin: "minimal" just means, "your runtime can add additional stuff if you want, but you must support at least this command-line API"
18:16:25 <wking> your additional stuff doesn't need to be CLI
18:16:34 <julz> yes, maybe with some sort of way of saying it's a vendor option?
18:16:39 <duglin> perhaps we should list the options here:  1) filesystem,  2) rest  3) cmd line  4) nothing and just define abstract action.  Anything else?
18:17:00 <wking> duglin: I think this discussion is more general, not just about /run/opencontainer/containers
18:17:00 <duglin> although 1 may still need 2 or 3
18:17:20 <duglin> 1 is just for sharing state, not necessarily actions
18:17:25 <wking> yeah
18:17:51 <duglin> so for actions,  rest  vs   cmd line,  is there anything else?
18:18:39 <lk4d4> gRpc, whatever :)
18:18:42 <lk4d4> a lot of options
18:18:57 <duglin> but ones we want to consider
18:19:09 <lk4d4> but I think actions is just keyword + config, which can be mapped to any scheme
18:19:50 <lk4d4> I like cmdline better
18:19:57 <mrunalp> lk4d4: you are suggesting something like for e.g. <runtime> action <json_describing_action>
18:20:00 <mrunalp> ?
18:20:08 <mrunalp> A simple cmdline like runc isn't bad
18:20:14 <lk4d4> yes
18:20:32 <lk4d4> I think just nature of spec is supposing local execution rather than "remote"
18:20:49 <lk4d4> so, cli more natural :)
18:21:01 <duglin> so back to state, do we want to have a “query” type of action?
18:21:01 <mrunalp> lk4d4: Agree
18:21:11 <mrunalp> REST could be added on top if one wants
18:21:13 <julz> lk4d4: xactly, yeah
18:21:16 <duglin> and then leave state management up to the impl?
18:21:18 <jlb13> yep, sure
18:21:19 <lk4d4> if there will be cases for it
18:21:31 <julz> I think yeah, but I'd prefer just query, not list, personally
18:21:32 <wking> #link https://gist.github.com/wking/1d69118ba8b750f85bfc
18:21:40 <julz> I think getting in to listing is probably higher level, personally
18:21:40 <mikebrow> "query" and "push"?
18:21:50 <wking> ^ my WIP based on julz initial work for the command line API
18:22:17 <jlb13> i agree duglin, i was thinking mgmt would be an upper layer concern
18:22:23 <RobDolinMS> mrunal: We should have a CL runtime state
18:22:47 <RobDolinMS> doug: Is this a query action that returns data or where to go find it?
18:23:04 <mrunalp> I think returining the data in defined json form would be good
18:23:13 <lk4d4> definitely
18:23:20 <duglin> yea, location of data isn’t ideal to me - just return the data
18:23:54 <duglin> of course we may need to deal with notifications at some point but I think that can be thought of after we define query
18:24:22 <mikebrow> kk query option
18:24:45 <duglin> I’m still hearing conflicting statements on the phone.
18:25:05 <duglin> we don’t need to talk about priv. if “query” returns state
18:25:14 <RobDolinMS> Jesse: There's a higher-level question here: how much of multiple instance state management will the CLI be responsible for?
18:25:58 <julz> jesse: strongly agree with that, runc should be 1:1 with a container, to me
18:26:11 <duglin> if it blocks then it seems we must support a 2nd instance of the exe being able to share state with the 1st.
18:26:17 <wking> yeah, I'm in favor of not handling state management in OCI
18:26:29 <wking> higher level can always plug it in via hooks
18:26:43 <lk4d4> wking: what is management?
18:26:45 <duglin> I’d prefer to leave this as an impl detail - as long as “some exe” can return state of a container I asked for then that’s enough.
18:26:58 <lk4d4> duglin: that was my thoughts too
18:27:16 <duglin> but I do think “query” needs to return “list of containers” because if 3rd party tool comes in late then it needs ot know what’s already running.
18:27:25 <wking> lk4d4: duglin points out that a 'func state --id <container-id>' command would have to get information from another func process
18:27:31 <mikebrow> Agree, 1:1 minimum requirement
18:27:33 <dqminh> so for tools like cadvisor, how will it discover applications in the system if we pun this to upper layer ?
18:27:35 <mrunalp> duglin: lk4d4: Yeah agree on that
18:27:51 <wking> passing that information between func processes is "state management" (or whatever, happy to use other terminology"
18:28:48 <julz> dqminh: imo that's a problem for a higher level spec/tool
18:28:56 <wking> jlb13: runtime implementation is much simpler if we punt state management to a higher layer
18:29:07 <duglin> leaving to the higher level leaves me wondering how we find out what’s running? If we say “ask the higher level” then the point of interop will be at that level not OCI
18:29:24 <mrunalp> duglin: docker starts runc wiht --id and stores it in a list
18:29:24 <wking> duglin: yeah, or put your own hooks in to keep track
18:29:36 <mikebrow> punt at the spec level but we can still implement a simple management example in runc
18:29:37 <mrunalp> It can then use that id to interact with that container
18:29:39 <mikebrow> ?
18:29:40 <lk4d4> wking: I don't think it will be easy
18:29:54 <lk4d4> what if you reconnecting to existing runc processes?
18:29:58 <julz> right, docker/cloudfoundry/kube etc. can all support a list command and just pass it to cadvisor, I don'
18:30:05 <julz> t think it's a huge deal if that isn't specified
18:30:19 <julz> but wherever it's specified shouldn't be oci, to me
18:30:22 <lk4d4> yeah, list is okay
18:30:26 <jlb13> yeah, that's how we do it with docker - docker manages its container instances, which are created/started/stopped by runz
18:30:27 <wking> lk4d4: I posted the content for emulating /runc/ in https://groups.google.com/a/opencontainers.org/d/msg/dev/q6TYqVZOcX8/GQs0zkRHBwAJ
18:30:34 <vbatts> so tying https://github.com/opencontainers/specs/blob/master/ROADMAP.md#define-standard-container-actions and https://github.com/opencontainers/specs/blob/master/ROADMAP.md#full-lifecycle-hooks together?
18:30:36 <wking> * emulating /run/opencontainer
18:30:42 <lk4d4> like oci state $(oci list)
18:30:50 <julz> 'cos at the end of the day, all of those high level tools will have to have a way to list anyway, and I doubt any of them want to delegate that down
18:31:04 <jlb13> right.
18:31:47 <lk4d4> my personal opinion is that list crucial if we have no standard state storage
18:32:02 <duglin> not sure how do to “list containers” with hooks
18:32:44 <lk4d4> there is no way
18:32:50 <mikebrow> a registry hook
18:33:04 <duglin> wking: but how do we get interop on “list” ?
18:33:08 <lk4d4> what if my "registry" app crashed badly?
18:33:13 <duglin> if each hook stores it differently
18:33:20 <lk4d4> only tool can be source of truth
18:33:28 <mikebrow> registry could be a file
18:33:44 <wking> duglin: why do you need interop on list?
18:33:45 <lk4d4> hehe
18:34:00 <RobDolinMS> #topic Updates on Roadmap
18:34:02 <lk4d4> yeah, files exactly what we want to avoid with dropping standard way of storing
18:34:03 <duglin> so some 3rd party tool can know what to monitor
18:34:24 <wking> duglin: you can tell the 3rd party tools what to monitor (so push to them, instead of having them poll)
18:34:27 <mikebrow> eggzactly
18:34:38 <RobDolinMS> mrunal: Lifecycle PR is close to being ready to merge
18:34:50 <RobDolinMS> mrunal: OCI Tools coming along nicely
18:34:51 <duglin> right, so the interop point becomes with the higher level not OCI
18:35:01 <wking> #link https://github.com/opencontainers/specs/pull/231
18:35:10 <duglin> if all interactions end up going thru the higher tool why do I need interop on OCI’s cmd line
18:35:30 <wking> "keeping a list of containers" is not "all interactions" ;)
18:35:38 <julz> I think interop almost has to be higher level, like what if I want to cadvisor only files owned by a certain user? are we going to get in to filtering and other things?
18:35:44 <RobDolinMS> mrunal: we have some agreement, who will work on this?
18:35:47 <julz> files->containers
18:35:51 <lk4d4> I agree with Doug here
18:35:51 <RobDolinMS> Doug: I'll work with Trevor
18:35:55 <RobDolinMS> Jesse: I'm in to help too
18:36:00 <wking> #action duglin work on command-line API
18:36:02 <lk4d4> oci tool always will have containers list
18:36:06 <wking> #action wking work on command-line API
18:36:19 <lk4d4> and it will be definitely more precise than any other list
18:36:21 <wking> #action jlb13 work on command-line API
18:36:21 <mikebrow> I think the idea was just to have a few helper examples of higher level management implementations to make oci useful without one of the higher level tools
18:36:37 <mikebrow> samples
18:36:53 <RobDolinMS> Vincent: What's the point of adding multiple owners?
18:36:57 <julz> if you want an OCI wrapper that gives you a list of containers that seems very easy to build on top of a defined standardised command line
18:37:06 <julz> without the command line having to pick up the ability to manage that state
18:37:24 <julz> no need even for hooks, just wrap the binary you call
18:38:33 <RobDolinMS> Vincent: Ideal to have one owner and additional participants
18:38:41 <RobDolinMS> Vishnu: I"m just back from travel
18:39:20 <RobDolinMS> #endmeeting