21:00:16 <wking> #startmeeting 2018-04-04 discussion
21:00:16 <collabot> Meeting started Wed Apr  4 21:00:16 2018 UTC.  The chair is wking. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:16 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:00:16 <collabot> The meeting name has been set to '2018_04_04_discussion'
21:00:49 <wking> agenda: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/B5qgXiKuQog
21:03:43 <vbatts|work> wking: thanks
21:05:14 <wking> #topic distribution-spec vote
21:05:28 <wking> if it didn't pass unanimously, it was pretty close
21:05:59 <wking> #topic certification
21:06:12 <wking> #link https://github.com/opencontainers/certification/issues/35
21:06:18 <wking> #link https://github.com/opencontainers/certification/issues/36
21:06:31 <wking> albanc: I'm trying to get the certification scope for the runtime spec
21:06:46 <wking> ^that's #36
21:07:02 <wking> albanc: Do we want to certify Docker and other higher-level engines?
21:07:17 <wking> albanc: I think for the moment we want to focus on runc and similar level runtimes
21:07:31 <wking> albanc: and for the image-spec, what is the certification focus
21:07:34 <wking> ^that's #35
21:07:53 <wking> albanc: is it just the image?  Also registries?  Conversion from the image-spec to a runtime bundle?
21:08:11 <cracra> [caniszczyk, Open Container Initiative] the initial thought was on registries but happy to discuss more
21:09:22 <wking> vbatts|work: I don't know if there will be much demand for "this particular Redis build is certified"
21:09:42 <wking> vbatts|work: I think it will be more like the W3C HTML validator, where you can feed in your image and get a pass/fail
21:10:00 <wking> vbatts|work: and something like "everything from this registry is compliant"
21:10:23 <wking> cracra: I have some recollection of registries not supporting multi-arch
21:10:36 <wking> vbatts|work: so maybe red/green/yellow, with multi-arch being a warning?
21:10:49 <wking> vbatts|work: Conversion was a bit controversial originally
21:11:03 <estesp> don't say "Alexa" :)
21:11:42 <wking> how can we certify implementations without specifying implementations?
21:11:47 <wking> stevvooe: ?
21:12:10 <wking> vbatts|work: you pass in something, but ... what are you passing in?
21:12:15 <estesp> wking: it wasn't always as clear that they didn't support multi-arch; in many cases there were parts of the v2 API that were used mainly in supporting multi-arch that registries decided wasn't that important for their use case
21:12:35 <wking> stevvooe: like in Docker you have a container, what would you drive on the Docker API to certify it for OCI runtime support?
21:12:53 <estesp> but definitely in some cases they were denying push when the manifest content-type was a "manifest-list"
21:13:03 <wking> mrunalp: for runtimes, it makes sense to certify the low-level runtimes (runc, hyper, ...)
21:13:25 <wking> crosbymichael: I think that makes the most sense.  But how do we word things that use runc?
21:13:47 <wking> vbatts|work: are we talking about dusting off the CRI discussion?
21:14:24 <wking> stevvooe: the conversion doc is also problematic.  What are we certifying?  Do we certify a CLI?  Do we certify the conversion spec, which I don't think is a good idea
21:14:39 <wking> mrunalp: for runc, it would be "if we implement a CLI we all agree on, then ..."
21:14:50 <wking> stevvooe: what if the implementation doesn't implement a random systemd flag?
21:14:58 <wking> mrunalp: then that flag shouldn't be in the CLI spec?
21:15:06 <wking> stevvooe: so which flags are in and which are out?
21:15:14 <wking> mrunalp: maintainers have to decide what makes sense
21:18:01 <wking> stevvooe: what value does this bring to the project?
21:18:48 <cracra> [caniszczyk, Open Container Initiative] section 1 for the OCI charter https://www.opencontainers.org/about/governance "The Open Container Initiative provides an open source technical community within which industry participants may easily contribute to building a vendor-neutral, portable and open specification and runtime that deliver on the promise of containers as a source of application portability backed by a certificati
21:18:58 <cracra> [caniszczyk, Open Container Initiative] that's where the certification program requirement comes from fyi
21:19:16 <wking> vbatts|work: rather than rat-holing on the point of it... folks want a tool to complaince test so they can get a green light
21:20:04 <wking> mrunalp: currently folk implementing a runtime have to reverse-engineer runc because we don't have an official spec
21:20:39 <wking> stevvooe: how often is this done?  Once or twice a year?  Certification is going to take a lot of effort/time
21:21:13 <wking> stevvooe: is the benefit that runc, ccrun, kata, etc. all have the same flags and run the same tests?
21:21:23 <wking> mrunalp: from a pluggable perspective, yes
21:21:38 <wking> stevvooe: but they're not pluggable, because the isolation primatives are different
21:21:55 <wking> mrunalp: we can have different flags for Windows/Linux
21:22:30 <wking> vbatts|work: when I floated the create, etc. JSON structure.  The reason that discussion happened was because any platform could take a JSON data structure and not have to depend on how Windows or other OS does flags
21:22:54 <wking> vbatts|work: I think a CLI spec would be pretty isolated to the platform
21:23:34 <wking> What's the Windows option issue?  Is it just -- vs. / conventions for options?
21:25:04 <wking> vbatts|work: circling back to certification#36
21:25:42 <wking> s/36/35/
21:26:10 <wking> crosbymichael: would image compliance help after the distribution-spec is in?
21:26:39 <wking> I agree that the distribution-spec would help with validating registries for serving compliant images ;)
21:26:52 <wking> vbatts|work: we tried to make the layout for local images, but yeah
21:27:21 <wking> stevvooe: you have a test image, you push it to the registry, pull it from the registry, and run it
21:27:46 <wking> stevvooe: but when I look at an individual image implementation or OCI implementation, looking at the runtime or image spec, it seems like we're just burning up C02
21:28:23 <wking> albanc: does that mean that image certification should be done only with the distribution spec, not on disk?
21:28:34 <wking> vbatts|work: I think layouts on disk would be another line item
21:28:58 <wking> vbatts|work: originally that was for 'docker save' and 'docker load', but you could have the same digests you'd have in a registry
21:29:30 <wking> vbatts|work: especially for end-to-end certification, the cert group could publish a test image digest, and folks could fetch it, run it, and look for exit 0
21:29:45 <wking> crosbymichael: I don't think you want to look at runtime exit codes, those are completely separate
21:30:10 <wking> crosbymichael: were layouts just a stop-gap?  How real is that use-case today?
21:30:28 <wking> crosbymichael: it may be less work overall if we're not making up things
21:31:14 <wking> crosbymichael: vbatts|work, you were talking about multi-arch validation?
21:31:57 <wking> vbatts|work: if an implementation couldn't fetch multi-arch images... It would be ideal if we had a big compliance up/down boolean.  But in reality, it breaks down to implementing all the MUSTs and some SHOULDs so yellow
21:32:11 <wking> vbatts|work: not even picking on multi-arch per-se
21:32:27 <wking> crosbymichael: and we have two sides of certification, producers and consumers
21:32:31 <wking> vbatts|work: yup
21:33:09 <wking> vbatts|work: even building an image doesn't mean it complies with the spec.  You can get an image in a few different ways and may want to test it before pushing it to a registry
21:33:24 <wking> vbatts|work: it would be good to be able to check each of those pieces at some point
21:34:02 <wking> vbatts|work: so albanc, I don't think anyone's in violent disagreement.  It comes down to how, when you look at any one piece, if it's an implementation detail or a compliance issue
21:35:10 <wking> vbatts|work: the other piece would be if you somehow specify that runtimes should comply with whatever capabilities, seccomp, etc., you could hand it a bundle to see whether the runtime could do that
21:35:47 <wking> stevvooe: there is a way for the image if you take a hash, walk the hash for the manifest and layouts, etc.  You could abstract out the fetching and run it on layouts or registries, and that's fine
21:36:10 <wking> stevvooe: I think there's less use for layer extraction, where it's tar based, and there are 40 years of inconsistent tar implementations
21:36:34 <wking> #link https://github.com/opencontainers/image-spec/pull/342
21:36:37 <wking> ^ tar spec ;)
21:37:05 <wking> stevvooe: but some of these do need to be left as implementation details
21:37:24 <wking> crosbymichael: would it help if we had two working groups, one for the runtime and one for images?
21:37:45 <wking> crosbymichael: and say, this is what we're certifying and this is what we're not?
21:38:02 <wking> Isn't that what runtime-tools is already?
21:38:56 <wking> crosbymichael: but runtime-tools and runtime-spec maintainers are running in parallel now
21:39:02 <wking> mrunalp: yeah, that makes sense to me
21:39:18 <cracra> [caniszczyk, Open Container Initiative] we attempted to try to do this awhile ago, it needs some love from the maintainers https://github.com/opencontainers/certification#certification
21:39:28 <wking> vbatts|work: what's out from the existing certification group?  Does it come down to this level of thing?
21:39:48 <wking> cracra: We talked about the process, whether it would be self-cert or peer-cert, etc.
21:40:04 <wking> albanc: is there a certification project?
21:40:15 <wking> cracra: it's not an OCI Project, it was under the trademark board
21:40:31 <wking> cracra: I think outside of mrunalp the maintainers weren't involved in that effort
21:40:34 <estesp> apologies; have to run for today
21:41:05 <wking> crosbymichael: when I proposed working groups, I didn't mean a separate thing.  I just meant a quick "let's work up a document" to say what gets checked, e.g. yes runc, no CRI-O
21:41:27 <wking> crosbymichael: and then vbatts|work's idea of pushing in a payload, we work that up after we know what we're going to certify and how
21:41:42 <wking> vbatts|work: I'm not opposed to a working group
21:42:16 <wking> cracra: if a working group is justed a google doc, I'm ok with that
21:42:26 <wking> cracra: as async as possible is best
21:43:01 <wking> #action cracra to open a certification-scoping Google doc
21:43:19 <wking> crosbymichael: and our focus will be on the low-level stuff
21:43:39 <wking> cracra: exactly.  The trademark can take care of the legal stuff, and this can be about what is actually certifiable
21:44:15 <wking> #topic runtime-spec 1.1
21:45:12 <wking> #link https://github.com/opencontainers/runtime-spec/pull/942
21:45:21 <wking> #link https://github.com/opencontainers/runtime-spec/pull/949
21:45:36 <wking> ^the two minor-level changes since 1.0.1
21:45:55 <wking> what happens to runc?  Will there be a 1.0 runc for the 1.0 runtime-spec?
21:46:10 <wking> mrunalp: we should meet and hash out the runc release
21:46:29 <wking> crosbymichael: or we can get a runc 1.0 out first and then circle back to runtime-spec 1.1
21:46:35 <wking> vbatts|work: so hold on runtime-spec 1.1?
21:46:38 <wking> crosbymichael: yeah
21:47:01 <wking> crosbymichael: there are also discussions about arguments going to the hypervisor
21:47:13 <wking> #link https://github.com/opencontainers/runtime-spec/pull/949#discussion_r178318374
21:47:26 <mikebrow> agree.. let's ga runc rc.6? before moving to 1.1
21:47:54 <wking> vbatts|work: we should open an issue about that
21:48:42 <mikebrow> tyranny to the implementation!
21:49:00 <wking> crosbymichael: if everyone is looking at runc, then the only one that's wrong is runtime-tools
21:49:53 <wking> I think there are some issues with the runc API, but we probably won't settle those in the next 10 minutes
21:50:06 <wking> #action crosbymichael to file an issue for https://github.com/opencontainers/runtime-spec/pull/949#discussion_r178318374
21:50:14 <vbatts|work> crosbymichael: https://github.com/opencontainers/runtime-spec/milestone/17
21:50:16 <wking> or maybe that was a vbatts|work action item
21:50:55 <wking> #link https://github.com/opencontainers/runtime-spec/milestone/9
21:51:42 <wking> vbatts|work: hmm, maybe v1.Y.0 is more of a label than a milestone
21:51:49 <wking> #topic distribution-spec project
21:52:03 <wking> vbatts|work: crosbymichael added his LGTM, so the vote is complete
21:52:18 <wking> #topic Copenhagen
21:52:23 <wking> cracra: albanc will be there
21:52:44 <wking> #topic distribution-spec
21:52:51 <wking> we plan on announcing this next week
21:53:09 <wking> stevvooe: when do you want me to drop the spec as it exists now?
21:53:27 <wking> cracra: before the 9th, when we announce it, so folks can look at it then
21:53:46 <wking> cracra: I've setup a GitHub group, and a maintainer set, etc.
21:54:06 <wking> stevvooe: I plan on decoupling the spec from route definitions, because the spec is currently generated from Go route definitions
21:54:14 <wking> vbatts|work: you don't want to carry that over?
21:54:26 <wking> stevvooe: yeah, it's fairly coupled to the implementation
21:54:39 <wking> stevvooe: and we could use that to generate some OAI
21:54:55 <wking> vbatts|work: whatever's easiest
21:55:07 <wking> cracra: yeah, and we can do OAI later down the line; whatever works
21:55:12 <wking> vbatts|work: anything else?
21:55:20 <wking> #endmeeting