# CNAB Community Meeting **Meeting time:** Every other Wednesday 9:00 AM - 10:00 AM US Pacific Time **Zoom Link:** https://zoom.us/j/653255416 **GitHub Repo:** https://github.com/deislabs/cnab-spec **Group slack channel:** #cnab @ cloud-native.slack.com (Get an invite from: https://slack.cncf.io) **Mailing list:** https://groups.google.com/a/opencontainers.org/forum/#!forum/dev **Document Link:** https://aka.ms/cnab/meeting **YouTube:** https://www.youtube.com/playlist?list=PLL6BzOBDywQeaaKFZkdt10JTZr5BxjQvQ ## Meeting Minutes and Agenda ## **July 24 Agenda** | | | | -------- | -------- | | Recording | | | Attending | | | Note Taker | | **Agenda** * New Folks * Demos? * Discuss: Validation through implementation (Jeremy) * 1.0 Working Group Approval (https://github.com/deislabs/cnab-spec/blob/master/901-process.md) **NOTES** **ACTION ITEMS** ## **July 10 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/kl_3I-1emXM | | Attending | Jeremy Rickard, Lachie Evenson, Darren (Intel), Leah Hanson, Glyn Normington, Silvin Lubecki, Vaughn Dice, Jacob LeGrone, Simon Ferquel, Ryan Moran, Matt Butcher, Simon Davies, Carolyn van Slyck, Ralph Squillace | | Note Taker | Matt Butcher **Agenda** * New Folks * Sorta new: Ralph Squillace * Please Review and Comment: * https://github.com/deislabs/cnab-spec/pull/218 - relocation mapping * Quick agreement that this is ready to ship * https://github.com/deislabs/duffle/pull/794 - keep bundle and manifest in sync * Recently identified bug, PR is straightforward. Just needs reviews. Silvin volunteered to review. * https://github.com/deislabs/duffle/pull/792 - small help text fix * Small tidy up. Just needs a review. * 1.0 * https://github.com/deislabs/cnab-spec/milestone/1 * Jeremy: Down to the end of things. #185 is ready to go * Butcher: Air gap can be moved to CNAB Spec 1.0 * Jeremy: Are we good otherwise? * Butcher: Can we go into "RC-like" phase? * Leah: Would prefer to discuss #204 * Renaming required actions * https://github.com/deislabs/cnab-spec/issues/204 * Butcher: Not too keen on doing this * Leah: We're provisioning or creating, not installing * Butcher: https://github.com/helm/community/blob/master/helm-v3/research/package-manager-ux.md * Leah: Significant difference is that the thing is not installed LOCALLY. Almost all of those things are installed locally. CNAB is not. CNAB creates resources elsewhere. * Ryan: Because you can create N intances (at N versions), this is a key difference from, say, a local package manager. * Spec calls an instance an "installation" * "create an installation", "upgrade an installation"... * Simon D: If it is not confusing, perhaps we should leave it. * Leah: Because bundles are more generic than merely installing applications, the term might be an understatement of what can be done. Took a lot of explaining to others to clarify this point internally. * Carolyn: Tools are free to use whatever verbs they want and map them onto the spec's verbs. * Ryan: So the runtime is mapping a user command to a different action name? * Carolyn: Yeah, the tool can provide a UX, but the bundle author would still have to use the install name. Tooling could even do things internally (like allow bundle authors to use their own terms for bundles). * Ryan: Bundle authors are the ones tripped up in our case. Hard to get them to understand what an action like "upgrade" is supposed to mean in the context of a bundle. * Ryan: Also need to update the claims spec to get rid of the term `release`. * Dependencies * Carolyn: Discuss current state vs desired state * Carolyn: We added an optional external [dependency spec](https://github.com/deislabs/cnab-spec/blob/master/500-CNAB-dependencies.md). But having it as an optional part of the spec makes it difficult to provide a consistent user experience. * Seems that this does not give a clear path for tooling that does not support the dependencies part of the spec. * Leah: One option is to add something that notes that a feature is required before the bundle can be used. * Glyn: I don't think dependencies is ready for core. * Consensus seems to have formed that we should add a capabilities check to the 1.0 spec. * Jeremy volunteered to draft. ## **June 26 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/c34aAoROeyw | | Attending | Chris Crone, Silvin Lubecki, Simon Ferquel, Matt Butcher, Radu, Lachlan, Jeremy Rickard, Leah Hanson, Ryan Moran | | Note Taker | Leah Hanson | **Agenda** * New Folks * Leah Hanson * Status Updates * Docker: updates to cnab-go and cnab-to-oci * Start tagging cnab-go ASAP please! * Open PR to start using go-modules rather than dep (todo link) * concerns about effects projects depending on cnab-go if cnab-go changes to go-modules, but duffle does not * Decision: wait until after 1.0 * Updates on cnab-go-ci & vendoring * Hard to manage -- depends on k8s, etc * It's a mess, work is being done * containerd had different opinion on how things should be implemented; will be fixed soon * [Rename Install/Uninstall #204](https://github.com/deislabs/cnab-spec/issues/204) * Everyone has opinions (there's no perfect option that we can just pick today) * Decision: give everyone a week to comment on issue * Decision: make poll of verb pairs to vote on * Summer holidays * How do we communicate that we're out and not ignoring people? * Set Github status (avoid issue assignment) * Set slack status to vacation * Set email responder * ... build cross platform api to set all statuses ... * 1.0 - Release end of Month or July 15th * No objections to delaying to July 15th * Decision: we will delay release to July 15th. * Status of issues: * There is a usecase for immutable property * Swapping image's platform (os/arch) field for the more generic label (string/string) * Air-gap scenarios checklist: export/import/signing package will work in airgapped network * Will new timeline work with maintainer schedules? * Urvashi & Glyn will not be back before July 15th. * Ryan has been anointed as proxy for both of them, so delay is not required. ## **June 12 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/xZWdPEVXMjk | | Attending |Urvashi Reddy, Glyn Normington, Chris Crone, Simon Ferquel, Jeremy Rickard, Karen Chu, Charlie PItkin, Radu Matei, Vaughn Dice, Swapnil Bawaskar, Jacob LeGrone| | Note Taker | Jeremy Rickard | **Agenda** * New Folks * Demos: * [CNAB 1.0 Spec Milestone](https://github.com/deislabs/cnab-spec/milestone/1) * [Discussion document on distribution, relocation, content addressing, and signing](https://gist.github.com/glyn/f1e4664747533594503b1404d1d8a9b6): 1. Relocation. Should the spec change so that relocation does not require a modified bundle to be created? For example, it could allow the image map presented to a bundle to be different from that in the CNAB. (See this [draft spec issue](https://github.com/deislabs/cnab-spec/issues/195)). 2. Distribution. Should we rework the proposed [805 section](https://github.com/deislabs/cnab-spec/pull/183) so that it doesn't touch on storing bundles in registries? 3. Distribution. What should `duffle import` do once thick bundles store images only in an OCI image layout? Should it simply import the bundle into duffle's private storage (and not load images into the docker daemon)? **Notes** - Relocation: when we do relocation, we produce a new CNAB; - 1.0: No major additions. @Matt Butcher asked if we could close the voting issue (178). Once the open PR from Ryan M merges, it should be. - Relocation/Distro/etc: - Simon: either approach is fine - Radu: allowing the image map to change wouldn't be a huge change, volunteered to do a PR - Glyn: if we mount entire bundle, we could get rid of original image and pass map - Radu will consider draft issue #195 when doing PR - Everyone seemed to agree with #144 - Urvashi volunteered to PR - Changes here in distribution, etc are ok, we only want to lock down 100 seciton for "1.0", milestone updated to reflect - Simon: OCI Layout can be imported with Docker Load, Might fail if multi-arch etc - We should probably only load invocation image into daemon, opt-in for others - Radu: Do we need others? Really only need invocation Image - Decision: duffle pull/import should load invocation mage, not others by default - Copy Silvin on issue to update that - Jacob L wants to do a follow up to #172 to capture other use cases so we can decide if needed before locking section 100 down. Action Items: - Urvashi: PR for #144 - Radu: PR for changes re image map - Jacob L: PR or Issue to capture image parameter type - Docker (Silvin?): PR to "docker load" import invocation image of thick bundle ## **May 29 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/GmM140msj50 | | Attending | Matt Butcher, Jeremy Rickard, Radu Matei, Glyn Normington, Ryan Moran, Simon Ferquel, Chris G, Carolyn Van Slyck, Steve Lasker, Vaugh Dice, Josh Dolitsky, Nuno do Carmo, Jacob LeGrone | | Note Taker | Matt Butcher | **Agenda** * New Folks * Demos: * Please Review and Comment: - [duffle PR 741: thick bundle relocation](https://github.com/deislabs/duffle/pull/741) still to be approved * Summary of CNAB and OCI registries discussion at KubeCon - https://hackmd.io/s/HyX_1znTV * Who are the core maintainers of libcnab-rust? * How do we feel about Core 1.0 Spec? **Notes** - Issue 741 was reviewed prior to KubeCon, but lost momentum. - Radu: Meetings at KubeCon revolving around the latest OCI and how OCI registries can be used to store different sorts of content - Additional media type: Agreed that this is a better solution than annotations - OCI all artifacts referenced by an index have to be in the same repository. It would be good to be able to reference external (remote) objects in a different repo or registry. This needs to be written up and proposed to OCI - Simon: Cross-registry references present a problem with verification: Can't be sure references remain consistent - Radu: Yes, but at least registry maintainers are open to discussion - Steve: It's not too different than foreign layer problems that exist (in Windows?) today. It's a choice (optional) to use this. Most of this is tooling-related: choice to move or not move - Glyn: Multiple media types in the same repository? - Simon: Docker (Hub? Distro?) requires this - Steve: Some people are more dedicated to the idea that a repository has just things of one type - Radu: If the spec allows these, then it gives users the ability to limit to one, or to use multiple types - Glyn: How can we test this? Radu: Probably can't. We'll have to come up with a fallback mechanism - Simon: CNAB-to-OCI does have some fallback mechanisms, and we could do this again when moving to the new OCI spec - Steve: Timeline for Docker to support new OCI? Simon: Not sure what has been decided - Radu: Last point: Should we store the bundle.json, and how do we handle signing (cryptographically)? We could do it like a trust server (TUF), or we could split the data into OCI manifest format and... (I lost the end of that sentence) - Simon: Image could be referenced by full location or by relative path (`example.com/foo/bar` vs `foo/bar`) so that hte bundle.json could be moved without image rewrites - Glyn: Can we sign bundle.json before pushing to registry (in Simon's relative path scenario) - Simon: Yes, we could sign the bundle.json and put it in the registry and be good, as soon as the images are in the registry (so we could get the digests from those). Could also sign the OCI index, and when we export a bundle, we can export an OCI layer file which will contain the index and the images. THen we could validate the signature. - Radu: Boils down to whether a bundle.json itself is valuable outside of the registry. If we don't need to move a bundle.json file outside of a registry, we could go the route Simon and I discussed. Otherwise, we should do it in an external signature registry. If the image is moved from one place to another, the digest changes even if the image doesn't. So we need to make sure that doesn't cause a security issue. - Radu: Is a bundle.json valuable outside of a registry? - Glyn: Yes, it is. The build step of that product can sign the bundle.json, and it can be transmitted to the user via other out of band methods. Pushing to a registry should not be a necessary part of a security flow. (Note taker nods in agreement) - Simon: It might not be the best way to share bundles via just bundle.json. Can also use OCI layered files for sharing (without registry). Air-gapped scenarios really needs layers to hydrate image. - Glyn: Agree with air-gapped, but we have a version where we want to sign a bundle.json that points to well-known existing location. This is different than the thick case. - Radu: If we sign full bundle.json and store it in a trust server, any relocation operation on those images will resolve in invalidation of the signature (changed locations) - Steve: Even in air-gap we still need a registry. We don't need a _third_ entity there. In Barcelona we talked about the location of where we get it is less important than whether we get the thing we want. It's the thing itself that we want to be signed. We need a first-class experience for choosing by content, not by location. Once the content is signed, it doesn't matter where it came from. - Simon: I am not sure what we had discussed before would cover what we are saying now. Relative paths for image would help, but it might not be as flexible as what you described. It's just a step in the right direction. - Jeremy: So what are the next steps for the registry? - Steve: It will be discussed on the OCI call today. There was a pretty productive move toward consensus at Barcelona. Whether the bundle.json is in the registry or not, we still haven't decided - Radu: CNAB-to-OCI is the closest to what we are talking about, so we are going to keep working on that - Jeremy: For Duffle, do we want that capability baked in? Radu: Yes, when CNAB-to-OCI is updated, we should merge that in. There may be other relocation issues that don't get merged yet. - Glyn: Can we post the OCI issues in the CNAB slack? - Radu: Store the entire bundle file vs storing the bundle... maybe we should have a standalone meeting on that. - Radu: We need to figure out what we want to do with the CNAB security specification. - Who are the core maintainers of libcnab-rust? - The moderator just volunteered to open an issue on that. Glyn and Jacob volunteered to help review PRs - Radu: Also, there's a .NET library that could use some help as well - Simon: We would like to prototype something that would add annotations to k8s Application CRDs and use that to deploy CNABs. - Do we forsee any big changes fpr 1.0 - Simon: maybe decide on storage bit before 1.0 - Ryan: required PR is still open. - we take the actual json schemas and pull out to top level def - within the param or output sections, just reference schemas - frees up conflict between json schema def and param/output definitions - https://github.com/deislabs/cnab-spec/issues/178 - Glyn: 3 for 1.0 - Airgap (https://github.com/deislabs/cnab-spec/issues/147) - Thick bundle naming( https://github.com/deislabs/cnab-spec/issues/171) - Images as parameters (https://github.com/deislabs/cnab-spec/issues/172) - Let's make a milestone to track these - Add standing agenda item to check in on Core 1.0 progress ## **May 15 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/rbruWY4u5ng | | Attending | Carolyn Van Slyck, Urvashi Reddy, Radu M, Karen Chu, Chris Crone, Michelle Noorali, Ryan Moran, Simon Ferquel, Matt Butcher, Matt Farina, Chris G, Glyn Normington, Silvin Lubecki | | Note Taker | Carolyn Van Slyck | **Agenda** * New Folks * Demos: * Announcement: CNAB joining JDF (and spec section 901 changed as a result) (Butcher) * Please Review and Comment: - [duffle PR 741: thick bundle relocation](https://github.com/deislabs/duffle/pull/741) * Parameters, JSON Schema and Required - See schema lines here: https://aka.ms/AA51xgl * Thick bundle spec issues (Glyn): - [intended usage](https://github.com/deislabs/cnab-spec/issues/173) - [tar file naming](https://github.com/deislabs/cnab-spec/issues/171) * CNAB to OCI (Chris C) * Adding a 1.0 and Post 1.0 Label * Rename `digest` to `content-digest` ([deislabs/cnab-spec#160](https://github.com/deislabs/cnab-spec/pull/160)) * Recent duffle CODEOWNERS procedural change: [PR 755](https://github.com/deislabs/duffle/pull/755) **Notes** * We are officially going to be a part of the JDF, just going through the paperwork over the next week (Matt Butcher). Choo Choo! 🚂 * Request for comment on thick bundle relocation [duffle PR 741: thick bundle relocation](https://github.com/deislabs/duffle/pull/741) * Parameters, JSON Schema and Required (going to vote on adding $ to required to make it reserved) TODO:carolyn fill in * https://github.com/deislabs/cnab-spec/issues/178 * Add a 800 section for thick bundles? * Condence the airgap issues into non-normative use cases (chris G) * Should we be storing vm's in OCI registries? Simon F suggests ORAS as a solution. Steve L says it's up to the artifact owner. * Need to be able to sha and checksum what is on disk (neccessary for airgap scenarios) Matt B. * Chris G - Need to be able to be able to make a binary blob that can hold multiple files (could be a VM) and we can evolve it over time with the spec. Need to get to V1 and iterate and get feedback from users. (CNAB oras artifact type?) * Lasker - Does a thick bundle even go into a registry or does it go onto a USB stick or CD? * Chris Crone - Can't guarantee that anything exists, even by SHA so you have to include everything in the bundle.g * Radu - Need to make a distinction between * CNAB to OCI Demo - Chris Crone * DTR - Docker Trusted Registry * Use existing OCI registry infrastructure * We can push images and keep the signature the same (trust). * bundle.json is decomposed into metedata and saved as annotations in the registry * The bundle hash is based on the decomposed metadata (which doesn't have the registry part anymore, because the images references all reference images within the same registry at this point). This lets us relocate without rehashing. See Simon's comment for more context. * Simon F: You sign the OCI index once, you can rellocate and validate it against the original signature. If rellocating breaks digital signatures we think it breaks security requirements for some airgapped scenarios * “OPA” = Open Policy Agent see https://github.com/open-policy-agent/opa/issues/1413 * See recording for more 🦙 * **Action Items** ## **May 1 Agenda** | | | | -------- | -------- | | Recording | https://www.youtube.com/watch?v=whGQ2XGriEc&t=4s | | Attending | Urvashi, Matt Butcher, Jeremy, Simon Davies, Ryan, Glyn, Radu, Chris G, Carolyn, Steve L, David Hoerster, Gabrielle | |Note Taker | Radu, Butcher | **Agenda** * New Folks * Demos: * JDF Update * storing CNAB bundles in OCI registries (Radu M - [working document](https://hackmd.io/s/rk4ph9-o4)) * duffle image handling (Glyn)![](https://i.imgur.com/Zz19f5J.jpg) **Notes** * Matt Butcher updates on on the JDF - Joint Documentation Foundation, part of the Linux Foundation. People and companies from the core maintainers group will be invited in the foundation, anyone interested in taking part in the process is welcome to join. * Radu Matei updates on OCI storage: Experimenting with multiple possible solutions. * Option 1: cnab-to-oci (open PR in Duffle). * Option 2: image-relocation: Relocate images into an OCI repository * Option 3: ORAS * We want to restart work on the registry specification * Radu has combined image-relocation and ORAS in one prototype to store all images in same repo with different tags. * Demo * Some discussion on the reasoning for push/pull with thick and thin bundles * For thin bundles, images can be stored wherever * For thick bundles, images are moved along with the bundle * Pivnet, for Pivotal, would be where bundle descriptors are located, and images in image registries * Should the repo spec say where the images be stored? Is this MAY, SHOULD, MUST? * Steve argues for SHOULD, since MUST is too strong, but the default is "everything moves together" * Glyn: Same repos on the same registry seems to be a legitimate solution (Steve agrees) * CNAB-to-OCI destructures the bundle to store it in separate layers. This makes it harder to meet the security specification. You have to reconstruct the bundle client-side, which seems a security risk. Does this invalidate the security spec? * Steve: Annotations, because optional, make me nervous. Use a config object? * Matt: I am nervous about having to "initially trust" data to assemble something against which the hash can then be verified * Glyn: It is fragile to reconstruct and then checksum * Transmitting thick bundles: Decomposing thick bundles to transmit them. Because there is no way to run custom code on the registry side, there is no way to compose it registry side, which seems counter to the spec. So perhaps the language should be upgraded to say that bundles cannot be destructured * Steve: What is the purpose of thick bundles? Why are they stored in the registry? * ref: https://github.com/deislabs/cnab-spec/issues/147 * Radu: There is documentation on that in the repo. * Chris, Steve, Radu: Some specific questions about the format in the layer diagram on the registry. Images are stored as TGZs in the layer... but [note taker lost track of conversation] * Thin bundle can still be pushed, preserving all of the image layer diagrams * Thick bundles, archived, can provide a single digest and does not require recomposition, which the layer diagram does require * Steve: But the thick bundle validation is still just a validation of multiple pieces. Advocating storing each part as a separate layer * Chris: We discussed much of this with Simon F, so we should pick this up again with him next week. * Glyn: Is it imperative that the thick bundle has not changed at all, or that merely that each part can be independently verified * Glyn's demo on relocation * See image above * The diagram is designed to show the different phases/representations of a bundle * Mainly, this is showing a difference between an import, and a relocation * Question is, do we need to have a step of pushing into a Docker Daemon, or can we require an internal registry * Would we want to revisit the idea of eliminating the Docker Daemon part and focusing on the relocation story? ## **April 17 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/MlXMXQGLejM | | Attending | Karen Chu, Jeremy Rickard, Josh Dolitsky, Chris Green, Carolyn Van Slyck, Glyn Normington, Silvin Lubecki, Sameer Advani, Gabrielle Bufrem, Radu Matei, Michelle Noorali, Urvashi Reddy, Simon Ferquel, Vaughn Dice, Ryab Moran| |Note Taker | Jeremy Rickard | **Agenda** * New Folks * Demos: * [insert demo here] * Inter-bundle dependencies: https://github.com/deislabs/cnab-spec/issues/156 * Outputs update: Aligning to JSON Schema like Parameters * Status of the image relocation PR ([deislabs/duffle#671](https://github.com/deislabs/duffle/pull/671)) + draft documentation PR ([deislabs/duffle#714](https://github.com/deislabs/duffle/pull/714)) * Status of the push/pull PR ([deislabs/duffle#681](https://github.com/deislabs/duffle/pull/681)) * This meeting will change from weekly to every other week. The poll in slack indicates that people would like to meet every other. See poll results [here](https://cloud-native.slack.com/archives/CEX1W7WMD/p1554914802093200). **Notes** - Pivotal opened issue discussing dependant bundles: #156 - Carolyn plans on opening a PR to discuss dependencies - Urvashi/Ryan interested in collaborating on that - See https://github.com/deislabs/cnab-spec/issues/156#issuecomment-482100944 - There was some discussion in OSB API about depending on soemthing that "provides" a thing (like a mysql), might be useful here - Glyn: Raised an issue in Porter #147. Carolyn: we were going to solve in just Porter, but better to do a more general approach - Glyn: compare [OSGi](https://www.osgi.org/developer/specifications/) bundle dependencies and beware ending up with a [NP-complete resolver](https://stackoverflow.com/questions/2085106/is-the-resolution-problem-in-osgi-np-complete). - Outputs: - Some concern about persistence of outputs - Tmpfs volumes recommended in spec - Runtimes handle what they eventually do with them - Simon will open implementation issue in duffle - Relocation: - PR is ready - Draft documentation is ready too - Radu: last chance for people to weigh in, been open for a few weeks please comment ASAP - Push/Pull: - We created a cnab go repo, has initial bundle client - Silvin has a PR open to use that in duffle - Push/Pull will use it, cnab-to-oci also - Should have a reviewable PR by end of the week - Meeting will change to every other week: - Next meeting would be May 1, that is week of DockerCon - We should create a calendar invite - Radu: we should do a duffle release next week - Simon: we should separate the runtime spec from the distribution spec, concerns mixed right now - Things in the spec like content digest are really distribution concerns - Thick bundles are also a distribution concern - Radu: should we do this before 1.0? Simon: probably best to do before 1.0, remove before 1.0 and maybe 1.1 bring back. Feels safer to have smaller spec for v1 - Glyn: not sure the oci parallel holds, bundles have image references so the split isn't as clean - Runtime probably needs to deal with thick bundles, could refactor the spec some to put concerns in a subspec - Simon: main point: should content validation happen in runtime? or does oci export handle - Chris G: can we have the runtime just validate but not do the relocation? - **We will continue this discussion in slack** **Action Items** ## **April 10 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/_pntGIQ5vnA | | Attending | Lachie Evenson, Jeremy Rickard, Glyn Normington, Silvin Lubecki, Chris Crone, Jason Stevens, Ryan Moran, Matt Butcher, Chris Green, Vaughn Dice, Gabrielle Bufrem, Sameer Advani | |Note Taker | | **Agenda** * New Folks * Demos: * Glyn: duffle relocate * Note: uses Pivotal's [image relocation code](https://github.com/pivotal/image-relocation). * Relocation design - Core question: Should invocationImages and images to be treated differently. Burden for artifact relocation logic (runtime?) (Chris). * Next steps on CNAB spec [issue 134](https://github.com/deislabs/cnab-spec/issues/134)/[PR 137](https://github.com/deislabs/cnab-spec/pull/137) (image map to include original image names) (Glyn). * Thick Bundle, CNAB-to-OCI, Registry discussion from Slack [#147](https://github.com/deislabs/cnab-spec/issues/147) [#142](https://github.com/deislabs/cnab-spec/issues/142) - "DeepExport" vs Thick Bundle * Proposal to change meeting frequency from weekly to every other week (Michelle) * Checking in on [PR 153](https://github.com/deislabs/cnab-spec/pull/153): Adopting JSON Schema in the Parameters section * Check in on CNAB bundle outputs (https://github.com/deislabs/cnab-spec/pull/133) - Jeremy **Notes** * Glyn demoed duffle relocate * Image map includes original images, so things can be updated/moved i.e. Kubernetes Configurations * Relocation design: * Chris Green added this. From Azure Global Team @ MSFT * This is issue https://github.com/deislabs/cnab-spec/issues/147 * Glyn's relocation demo does some of this work * cnab-to-oci does the same (the fixup operation), used in Docker App * Also caches the images in home directory so you can see invocation image + others on disk * Chris G will try and coordinate with Chris Crone and Glyn to land on a solid story * Michelle: Should we consider turning the images map into a new type of parameter? Michelle will open a PR * Ryan: Parameters in the bundle are JSON schema, you as bundle author would be able to write JSON Schema to describe parameters. * Simon raised a concern that each string being full json document vs a simple string, Ryan thinks could it be a runtime thing. Chris: Simon's issue is mainly around usability * Matt: metadata object goes away, so it's a breaking change if this goes in * Matt: we seem to be arriving at a consensus, PR open for comments * PR 137: Image map should contain before/after info so it can do relocation as necessary * Digest can change in a relocation, so maybe we should include that too * Chris G interested in digest being in there * Michelle: would love to know how to preserve digest * Glyn: the [image relocation code](https://github.com/pivotal/image-relocation) preserves digests thanks to the design of its [go container registry](https://github.com/google/go-containerregistry) dependency. * Meeting frequency: should we move to every other week? * Will put it to a vote in the slack channel. **Action Items** ## **April 3 Agenda** | | | | -------- | -------- | | Recording | | | Attending | | |Note Taker | | **Agenda** * Cancelled due to lack of agenda (lachie83) **Notes** **Action Items** ## **March 27 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/iljd1IRwofs | | Attending | Glyn Normington, Jeremy Rickard, Radu Matei, Michelle Noorali, Ryan Moran, Chris Green, Urvashi Reddy, Darren from Intel, Karen Chu, 1 or more people from Pivotal Cambridge, Silvin Lubecki, Swapnil Bawaskar, Carolyn Van Slyck, Simon Davies, Steve Lasker, Ralph Squillace| |Note Taker | Jeremy Rickard/Karen Chu | **Agenda** * New Folks * Demos * Discuss duffle image relocation requirements (with a view to planning how to implement [duffle issue 668](https://github.com/deislabs/duffle/issues/668)): * One-one repository mapping, mainly for human readability * Support for CNAB (optionally) _not_ to be stored in a registry, required for incremental adoption of CNAB * image relocation vs. storing bundles in registries (continuation of image relocation requirements discussion) * Go client for CNAB * avoiding circular dependencies * simple vendoring for projects trying to use code from Duffle **Notes** * Glyn: Concern about cnab-to-oci for relocation use cases * Push/Pull different requirement than relocating bundles * Image Relocation: * Take image prefix (gcr.io/myuser), modify all images to have that prefix * Radu: agree having different things happening during relocation vs relocation might be annoying, but they are different use cases * Radu: everyone ok with us continuing with push/pull and rewrite and seeing if we can converge next week? * Go Client: * cnab-to-oci took a dependency on duffle bundle pkg * trying to add cnab-to-oci to duffle * circular dependency * Radu has created a new repo for a cnab go client that can be referenced from duffle and other tools (https://github.com/radu-matei/cnab-go) * Carolyn: we are trying to use a lot of Duffle in Porter, lots of good logic in the cmd package * Radu: we use Docker CLI and thus have dependencies; we have an open item to move to Containerd * Ralph: we will want to extract as much as possible for flexibility and design * we still have a lot of things to pull out of the main pacakges of Duffle; whatever is in Github should be part of the Go client * Porter will supporter claim storage in the future * ideal for people to pair to pull packages out of the client * Urvashi: Add `schema` field to parameters section ([PR #145](https://github.com/deislabs/cnab-spec/pull/145)) * Michelle: makes sense, wondering what things in Duffle this effects and what the implementation looks like, will look into how import/export looks like * Radu: this will effect downstream * current state of PR isn't JSON schema conformant but can be; clients can validate that themselves * will start a second PR to compare and contrast * Duffle push/pull is in a rough state * Michelle: what digest field actually means * local Duffle build -- don't have Docker manifest; what exact should go into the digest field, if anything? * What do you take a hash of to verify image of what you want? How do you make it so that it's not dependent on a registry component? * will write up an issue **Action Items** * Urvashi: second PR for adding `schema` field to parameters section * Michelle: PR for what a digest field actually means ## **March 20 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/7DpeT4I0pnI | | Attending | Lachlan Evenson, Ryan Moran, Silvin Lubecki, Nuno do Carmo, Jason Stevens, Simon Ferquel, Radu Matei, Urvashi Reddy, Josh Dolitsky, Vaughn Dice, Jeremy Rickard, Darren (Intel), Sameer Advani, Glyn Normington | |Note Taker | Jeremy Rickard | **Agenda** * New Folks * Demos * Summary of Changes: https://hackmd.io/s/SJxpDvTLN * Please Review and Comment: * https://github.com/deislabs/cnab-spec/pull/137 * https://github.com/deislabs/duffle/issues/668 * Should custom extensions be exposed to invocation images? * What are the goals or use cases for libcnab-rust? * JSON schema support? **Notes** * libcnab-rust: * Partially becuse we want to learn RUST * We are trying to exercise parts of the spec in other languages * Re: Should custom extensions be exposed to invocation images? - Can we expose extension metadata to the invocation images? - Simon suggests that more generally, it would be good to add additional properties across the spec (friendly names for parameters and what not) - Glyn will raise an issue to cover this, add to meeting notes: CNAB spec [issue 143](https://github.com/deislabs/cnab-spec/issues/143) raised. * JSON Schema Support: * Urvashi - would it be possible to update cnab spec to adopt JSON Schema wholey * Part of effort to enrich parameter definition to allow JSON Schema definition for more complicated type * Butcher: currently missing object and array types * Simon: suggest that we embed validation into invocation image and define a way to report validation errors * parameters - they look very much like JSON schema, but does not adhere to the JSON schema - difference between valid string in the JSON schema and a valid string in the CNAB parameter - in the runtime, there is a JSON API that sends parameters -- painful experience, where there are regular JSON payloads that need to be converted into the String type of the CNAB parameter - is the bundle.json format supposed to be human readable, exposed to users? - thick bundles and air-gapped environments - Docker Compose example -- invocation image embeds the logic to provision the images on the cluster - at least for OCI images, we should have a registry in the air-gapped environment, and the images would be re-located there - do we need thick bundles at all for this scenario? We can copy things from one registry to another - this works for OCI images, no scenario for other images (VMs) - until the VM story can be satisfied, we still need thick bundles - great to copy the images during relocation (in a DMZ), but other locked down scenarios don't have internet at all, PLUS long term support - the duffle implementation of image relocation could handle both thin and thick bundles **Action Items** - Glyn open issue for #143 - Urvashi/Ryan: open PR with the json schema stuff - butcher: list all air-gapped scenarios and decide if we need thick bundles ## **March 13 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/rss-Npo9h8A | | Attending | Chris Crone, Caroyln Van Slyck, Ryan Moran, Karen Chu, Urvashi Reddy, Matt Butcher, Radu Matei, Nuno do Carmo, Chris Green, Josh Dolitsky, Silvin Lubecki, Michelle Noorali, Swapnil Bawaskar, Vaughn Dice, Gareth Rushgrove, Jeremy Rickard | | Note Taker | Jeremy Rickard | **AGENDA** * New Folks * Demos * Carolyn: Porter + JSON Schema * Please Review and Comment: * https://github.com/deislabs/cnab-spec/pull/133 * https://github.com/deislabs/cnab-spec/pull/137 * Summary of Changes: https://hackmd.io/s/SJxpDvTLN * Proposal: Relax MUST use Canonical JSON to SHOULD use Canonical JSON * Plans for duffle rewrite or similar? * Should custom extensions be exposed to invocation images? **NOTES** * Porter and it's mixins present JSON schema now, that drives IntelliSense for VS Code - If you install other mixins, will they get incorporated? - Mixins *can* expose schema but they aren't required right now - How can you generate the mixin? - Right now we did it by hand, but there is a wide range of tooling but different versions aren't compatible with different tooling * We'd like to merge 133 and 137 soon. Additive but useful. * Relax MUST use Canonical JSON? * Collectively discovering Canonical JSON isn't terribly well supported * Might limit the support of libraries in other languages * Chris: sounds reasonable, checking signature after decoding binary feels wrong * From chat: should we change images back to array from a map * would be a breaking change need to decide soon * check with Silvin or Simon from Docker as to why that is the form (check with them in cncf slack) * tooling can have their own manifest files that represent in different ways * Start a discusison in #cnab channel in CNCF slack * Plans for Duffle Rewrite: * Pivotal asked * Current plans probably should be in the invocation images themselves * Follow up from last week docker socket: docker is making that change, we should add to best practices for runtimes * Consider the spec in _slushy_ state and try not to make breaking changes between now and June. **ACTION ITEMS** Jeremy: * Add _Should custom extensions be exposed to invocation images?_ to next week's agenda ## **March 6 Agenda** | | | | -------- | -------- | | Recording | https://www.youtube.com/watch?v=yFOfyX7BSyg | | Attending | Carolyn Van Slyck, Michelle Noorali, Karen Chu, Josh Dolitsky, Chris Chrone, Glyn, Jeremy Rickard, Nuno do Carmo, Radu Matei, Steve Lasker, Urvashi Reddy, Gabrielle, Sameer Advani, Daniel Fein, Ryan Moran | | Note Taker | Jeremy Rickard | **AGENDA** * New Folks * Demos: * CNAB push -> promote -> pull demo (simon aka Chris :) * Authoring Porter bundles with Lua & MoonScript (Josh) * Source code: https://github.com/jdolitsky/porter-moon-demo * Please review: * https://github.com/deislabs/cnab-spec/pull/123 (breaking change) * https://github.com/deislabs/cnab-spec/pull/131 * Summary of This Week's Changes: https://hackmd.io/s/SJxpDvTLN * Running invocation images as privileged containers with Duffle -- [deislabs/duffle#651](https://github.com/deislabs/duffle/pull/651) (Radu) * Add Maintainers * Require 2 LGTMs? * (If time) Discuss next steps for https://github.com/deislabs/cnab-spec/issues/95 ** NOTES ** - Chris Crone from Docker demoed cnab push -> promote -> pull - [Docker App](https://github.com/docker/app) - Push Pull with [CNAB-To-OCI](https://github.com/docker/cnab-to-oci) - Apache 2 license, feel free to use it - Question from Michelle: Do you calculate the hash locally or on push - Answer from Chris: On Push because it depends on the layers being archived in registry - Steve Lasker: still a burder on registry to understand how they are stored, registries may not have all info they need - Chris: We need to define annotations to define how to identify, later we can make a better solution - Question (from Radu): Is there a signed bundle story yet - Answer: We aren't doing signing yet - Question (from Radu): How do the artifacts arrive? - Answer: push referenced images first, then push invocation image, then push oci index - Josh Dolitsky demoed Lupo and Moopo - Build porter bundles using [Lua]([https://www.lua.org/) and [Moonscript](https://moonscript.org/) - Created issue in Porter [#207](https://github.com/deislabs/porter/issues/207) to investigate how to integrate lupo and moopo more tightly with porter. - Privileged invocation images - DO WE DO IT OR NOT - Duffle used to mount the socket all the time - We've removed that - Question: other than demo scenarios, real world scenarios where you'd want to run privlidged invocation images (i.e. modifying the same docker engine that you're running in) - Handle we support that with --privledge? - Chris: Don't do it by default, but you should have an option to tell the driver to run it as root, mount socket. Leave it up to the tooling. - Radu: do we have clear guidance on how to provide Docker URL and Certs for how to do production like things. - Chris: we've added docker context support for Docker CLI. It requires latest Docker app and docker CLi right now. You can specify contexts and it passes stuff in. - Chris: Hope to contribute this upstream to Duffle (PR is up: https://github.com/deislabs/duffle/pull/661) - Maineriners and LGTM+2 - Michelle suggests the Helm policy for nominating maintainers - 2 LGTMs seems like a good idea now - Issue 95: - Follow up conversation needed - Michelle might propose adding an artifacts manifest for thick bundles so tooling can know where to place things ** ACTION ITEMS ** * Michelle will PR a maintainers governance document based on Helm to nominate new maintainers ## **February 27 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/wlkoi5ga6V8 | | Attending | Jeremy Rickard, Ryan Moran, Nuno do Carmo, Urvashi Reddy, Gareth Rushgrove, Glyn Normington, Radu Matei, Lachie Evenson, Matt Butcher, Steve Lasker, Michelle Noorali, Carolyn Van Slyck, Karen Chu, Jason Stevens, Josh Dolitsky, Vaughn Dice, Matt Fisher, Gabrielle, Sameer Advani, Chris Green | | Note Taker | Lachlan Evenson | **AGENDA** * New Folks * Demos: * CNAB/porter wsl demo (Nuno) * CNAB push -> promote -> pull demo (simon) [Please schedule for next week instead] * [lupo](https://github.com/jdolitsky/lupo) - PoC of using Lua to build Porter bundles (Josh) [maybe next next week] * Tooling request for help (are you working on a CNAB tool and need help?) * CNAB core spec 1.0 progress * Release notes / summary of spec changes (jeremy)? * Spec proposal for JSON on STDIN - [deislabs/cnab-spec#114](https://github.com/deislabs/cnab-spec/issues/114) * Self-contained documentation for bundles (Radu) - [deislabs/cnab-spec#118](https://github.com/deislabs/cnab-spec/issues/118) **NOTES** * Should we run things outside the invocation image but rather directly on the host operating system? We could build a rkt driver potentially that unbundles and image. (based off the details in Nuno's demo) * Have CNAB core-spec to stabilize by the end of the week * There are four specifications in cnab-spec repo. Core, Repository, Security, Claims. Also non-normative has been moved out to the 800 section. * Question - Core is the only mandatory specification. We want people to be able to say, we are cnab-spec compliant. * Are image drivers in or out of the spec? The drivers are part of the duffle implementation and are not part of the spec. * Spec proposal for JSON on STDIN - parse data over STDIN directly in to the run tool via "Stdin: true". What happens if you have that on two parameters? How do you know what parameter is what? * Discussion around support object, or array with declared schema and have JSON schema validate. * Documentation discussion - having a directory within the bundle that can be stored as an OCI layer and then parse by the repository. Updates to core-spec would be a refence to a directory and a description field. https://github.com/deislabs/cnab-spec/issues/118 ## **February 20 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/jG1N8QnYUjE | | Attending | Lachlan Evenson, Jeremy Rickard, Josh Dolitsky, Matt Butcher, Daniel Fein, Carolyn Van Slyck, Karen Chu, Chris Crone, Adnan Abdulhussein, Gabrielle, Nuno do Carmo, Radu Matei, Sameer Advani, Swapnil Bawaskar, Urvashi Reddy, Vaughn Dice, Simon Ferquel, Ryan Moran, Atlas | | Note Taker | Lachlan Evenson | **AGENDA** * Demos: * Short update on TUF/In-Toto design * alpha/beta releases of spec in run up to 1.0 * Storage of CNABs in registries * Feedback on [CNAB to OCI](https://github.com/docker/cnab-to-oci/pull/19) update * Naming of common credentials * May not age well in the spec * Align tool builders on common credential names (i.e.: kubeconfig, etc.) * Would CNAB be an appropriate place to host a spec related to storing multiple content types over OCI? (Josh Dolitsky) * OCI maling list discussion: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/idUW9KWQsBo * Porter + Lua (Josh Dolitsky) * https://github.com/deislabs/porter/issues/173 **NOTES** * Security currently direction switching from open pgp to [TUF](https://github.com/theupdateframework/notary) and [In-Toto](https://in-toto.github.io/)? * Proposal of third specification on security. Optionally implmentable without affecting cnab core compliance * Matt Butcher is working on the draft hopefully finished by the end of the week * Questions? * Will this tie into registries? Yes and with notary * Will all the specs go v1 at the same time? Currently not sure. * Identified security issue in Duffle "duffle docker driver mounts the docker socket for no apparent reason. That gives CNAB invocation images a wide open door to your machine.
(Will write an issue on Docker repo for this one)
" * We shouldn't have aplha and beta of the releases to stop fragmentation. When will the core part of the spec be v1. * Move fast on cnab core and get it to v1 * What is the current rate of change and how many tools implement the specificiation * Chris proposing CNAB to OCI tool be used to store bundles in registries * Where should the CNAB registry storage conversation be had? * Discussion around tight coupling of image spec and distribution spec * Challenging to make changes to OCI distribution to make it a generic store because every tool has different use-cases * Annotations are the best way forward with custom types * Start with standard agreed upon key then move forward with the implementation * DECISION: Move forward with CNAB to OCI and continue discussion in OCI distribution. Agree on annotation across communities. Simon to help with pulling CNAB to OCI into Docker-app * CNAB to OCI doesn't currently support thin-bundles.Simon and Chris to raise issue to hash out the detail * Thin bundle = main OCI Index + config blob * Thick bundle = Thin bundle + deep copy of everything linked by the main OCI index
 * Well known custom actions - https://github.com/deislabs/cnab-spec/blob/master/805-well-known-custom-actions.md * Porter mixin for CNAB that makes a single bundle from multiple bundles * As soon as the spec has any way to communicate outputs between bundles then we could compose bundles as you suggest. Until then I think it would be a bit clunky. Like you could run a bunch of bundles, but without being able to pass data between them, it wouldn’t be as useful as I would want, no? * Jeremy has proposal and will open PR **ACTION ITEMS** * https://github.com/deislabs/cnab-spec/blob/master/101-bundle-json.md#the-image-map -> refs and image map injection at runtime is redundant * https://github.com/deislabs/cnab-spec/issues/113 ## **February 13 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/d3EOrtsCd7o | | Attending | Jeremy Rickard, Radu Matei, Matt Butcher, Ryan Moran, Urvashi Reddy, Chris Crone, Karen Chu, Lachlan Evenson, Carolyn Van Slyck, Vaughn Dice, Simon Ferquel, Swapnil Bawaskar, Silvin Lubecki, Adnan Abdulhussein, Nuno do Carmo, Sameer Adveni, Daniel Fein, Josh Dolitsky, Simon, Gabrielle, Glyn Normington| | Note Taker | Jeremy Rickard | **AGENDA** * Demo: Porter * What's chang(ed|ing) in the spec since last week * Metadata: License * Namespacing rules * Canonical JSON * Proposed: JSONSchema subset for params * Proposed: Remove CNAB_P_* * Commit on storing CNABs in registries * Explanation of chosen method * How and when should this be added to the spec? * Short update on TUF/In-Toto design **NOTES** **Lots of new people again, thanks for joining us!** * Porter Demo * Links to Porter * https://porter.sh * https://github.com/deislabs/porter * Question from nuno: * currently testing the exec mixin, but will the other cnab “clients” be able to run it too? (and yes I would totally understand if I’m out of scope)
 * Answer: Hey Nuno, right now they are porter concepts. So they work w/ the Porter build / porter run flow. Once you build the bundle, you could run that in other tooling, but right now the porter runtime knows how to invoke them
 * Question from glyn: * How do people know how to use mixins * Answer: Mixins provide a schema that returns JSON schema * Canonical JSON * Moving to Canonical JSON for CNAB is preferred * One pro per Radu: "And a lot more language implementations for canonical JSON serializers..""
 * Proposed: JSONSchema subset for params * Ryan Moran has been working on a proposal. No PR yet. * Has been chatting with Matt about it. * Would introduce more strcture to parameters * CNAB in Registries * see repo below for example of what is the current thought * CNAB to OCI: https://github.com/docker/cnab-to- oci/blob/13c4adaaf091e6f996116aff5ecc3f0eb6a3dd20/README.md#example * Matt Fisher: thinks its a good idea * Chris Crone [10:51 AM] For those interested in how CNAB and other artifacts are stored in registries, there's a #artifact-registry channel now * Did not cover the TUF/In-Toto Design updates * We decided to extend the meeting for next week. The invite will get updated. **ACTION ITEMS** ## **February 6 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/_E1R3mip6aY | | Attending | | | Note Taker | | **AGENDA** * Spec decomposition (claims, runtime, etc) * Storage of CNABs in registries * Common repository for test data (client conformance) - https://github.com/deislabs/cnab-spec/issues/90 * Strategies for keeping the spec, bundles, and implementations in sync (for example https://github.com/deislabs/cnab-spec/issues/92) * Tooling overview * [Duffle](https://github.com/deislabs/duffle/), [Porter](https://github.com/deislabs/duffle/) * [Docker App](https://github.com/docker/app) * [Python Client](https://github.com/garethr/pycnab), [.NET Client](https://github.com/deislabs/cnab-netstandard) * If you are working on something, please submit a PR and list it on https://cnab.io/community-projects/ **NOTES** * Introduction - everyone's awesome, again * spec decomposition * different stabilities for different parts * should x be part of the spec? * storage of CNAB bundles in registries * Gareth gives a quick background for the registry discussion * Steve L - it is agreed that we want to store additional artifacts in registris with the OCI folks, we are at the point where details are discussed. * how to let specific teams that are in charge of different artifacts own the specific artifact schema * anyone interested in this discussion, join the weekly OCI meeting, today (Wednesdays) at 2pm pst: https://calendar.google.com/calendar/ical/linuxfoundation.org_i0sado0i37eknar51vsu8md5hg%40group.calendar.google.com/public/basic.ics * OCI mailing list conversation: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/oguystbnnw4 * additional repo with test data * we want to have a common place for test data to use with various implementations * how to validate that a bundle is valid with a version of the spec? * the Python implementation already started some work on validation **ACTION ITEMS** * create a repo for a bundle validator * create a common repo for test data * Rename the bundles repo to bundle-examples or something to indicate its purpose better (that they show what a bundle looks like with the raw CNAB spec, not duffle or porter, etc) --- ## **January 30 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/a7cqHpTrDTY | | Attending | Matt Butcher, Michelle Noorali, Jeremy Riickard, Brain Redmond, Adnan Abdulhussein, Miguel Martinez, Radu Matei, Chris Crone, Gareth Rushgrove, Silvin Lubecki, Carolyn Van Slyck, Matt Fisher, Lachie Evenson, Phil Estes, Augustine Correa, Michele Buccarello, Peter Benjamin, nalla | | Note Taker | Jeremy Rickard | **AGENDA** * Introductions * tldr; Everyone is pretty cool * The current proposals for storing CNAB in registries * Two approaches * Chris Crone is attending OCI meetings * Status report on spec * Made changes to how to specify images in the spec * Makes it easier to switch registry information * Merged * Part of larger story for getting OCI registry support * Spec evolution defined in [CNAB Spec Section 900](https://github.com/deislabs/cnab-spec/blob/master/901-process.md) * The current proposal for switching from OpenPGP to TUF * The changes to the `images` section on the spec. **NOTES** * OCI Meeting today will discuss OCI spec adoption * https://github.com/opencontainers/runtime-spec#meetings * https://www.uberconference.com/opencontainers * Can OCI dev open containers mailing list be used or will we use another * As spec changes, we need a way to have example bundles verified * Currently checks that duffle can install bundles * Can/should add schema validation * Should Claims be in the spec? * Possibly move toward a more componetized spec * Add to agenda next week: discuss decomposition of spec * Michelle gave an update on Duffle * Doing some refactor of builder, split image and bundle * We've created a [waffle.io board](https://waffle.io/deislabs/duffle) * Move TUF discussion to next week * If you have tooling demos, feel free to add to the agenda for upcoming weeks * Michelle: A useful thing as people start proposing/doing conference talks, we should make a repo somewhere that we can store collateral/images/etc for everyone to reuse * Should we put it in deislabs? * Let's make a community repo **ACTION ITEMS** * Matt Fisher and Radu Matei to start working document on how to store CNAB in OCI registries * Lachie add action item for Agenda next week for spec decomposition * Michelle and Carolyn to make a community repo in deislabs ---