# 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 ## **Sept 25th Agenda - Dependencies** | | | | -------- | -------- | | Recording | | | Attending | | | Note Taker | | ## **Sept 18th Agenda - General Meeting** | | | | -------- | -------- | | Recording | | | Attending | | | Note Taker | | **Agenda** * New people? * https://github.com/deislabs/cnab-spec/issues/279 (Leah) * jrr: does this lead to 1.1? * Running custom actions in duffle (Urvashi) * Move cnab-spec, cnab-go, duffle to a non-deislabs repo? (Jeremy) * Demo dependencies implementation in Porter * Maybe set up a separate meeting to discuss dependencies use cases and what would be useful to have in the spec vs. what we thought we would need and didn't really? * Porter demo from HashiConf: https://www.youtube.com/watch?v=ciA1YuGOIo4 * Check it out on your own if you want to see it! * New contributor changes (carolynvs) * Ladder: https://github.com/deislabs/porter/blob/master/CONTRIBUTING.md#contribution-ladder * Look for people to promote at our regular meetings * Updates on [CNAB-Sec](https://github.com/deislabs/cnab-spec/pull/253): split into three (Trishank) * 301: Metadata repositories (normative) * 302: Signing workflows (normative) * 303: Verification workflows (prescriptive) * Move export code from Duffle to cnab-go (Jeremy) * Experiment v1/v2 change for OCI index config object (Radu) **Notes** * Newcomer: Joe (Pivotal) * Leah on [issue 279](https://github.com/deislabs/cnab-spec/issues/279): Credentials and Parameters should have the same structure. * Glyn: would it be backwards-incompatible? * This might have to be 2.0, not 1.0 * Urvashi: why not just Parameters, and remove Credentials altogether? If the structure is the same, there is no semantic difference between the two. * Carolyn: that is not the difference. Credentials are for whoever / whatever is executing the bundle, Parameters are more generic and can be used by anyone or anything. There should be an audit trail that distinguishes the two. * It's confusing to have Credentials and Parameters, because the exact differences are not clear. This needs to be resolved in 2.0. * Jacob: there needs to be a way to distinguish sensitive vs nonsensitive Parameters. Carolyn says that there is write-only. Jacob thinks this should be clearer in the spec, although Carolyn and Radu say that it was already clarified running up to 1.0. * Radu: Do we have other things that are waiting on 2.0? * Jeremy: each one should get their own meeting. * Summary: * This change would be breaking; needs 2.0. * There is discussion on sensitive vs. nonsensitve parameters and how exactly to make the change. * How to work on this going forward: starting working group to discuss. starting milestone to track 2.0 issues. * Running custom actions in Duffle. * Can run a custom action independent of bundle definition * Jacob: should we be able to run a stateless action without a claim? * Urvashi and Radu: Yes, you should *only* be able to run *stateless* actions without a claim. * Summary: make Duffle only depend on the installation state that is in the claim (for stateful custom actions). * Should we move everything from the deislabs org to somewhere else? * The thinking is to make at least one new, independent-looking org. * Jeremy: we can make new teams to have better access control. a new org is neutral ground for collaboration. * Glyn: can we switch to go modules at the same time? Since they both impact consumers & we should minimize the number of times we break imports. * Carolyn: two steps to boil the ocean, please. makes it easier to see what broke people. wants people to be able to figure out why their imports broke. * Glyn: so get to 1.0 in deislabs, switch to go modules, then switch github orgs. * Carolyn will demo what dependencies look like in Porter (see the recorded meeting around the 24m mark) * We are going to have a separate meeting in the off week * Jeremy on CNAB presentations at HashiConf * Carolyn added a contribution ladder to porter * Carolyn: make sure to ask continual contributors in meetings to become maintainers * Summary: Carolyn will PR the same contribution ladder to the cnab-spec/cnab-go/duffle repos. * Trishank talks about the changes to the security spec * there is a split between the required and optional aspects of the specification * 3 new PRs to accomplish this in the cnab-spec repo * Radu encourages everyone interested to join the OCI Slack to discuss security for OCI Artifacts, which face many of the same issues as we do * Jeremy moved export code from Duffle to cnab-go * Newcomer: Chriss T (Citrix) introduced himself * Radu's going to look at the changes required for representing bundles in the OCI Index. Are they breaking or additive changes? * Jacob says dependencies would involve a standard way of referencing / pulling bundles. * Radu says Porter already has a stable library for referencing / pulling bundles, but it's not a standard way to do it (Annotations are optional in OCI). * We will demo cnab-to-oci next time. **Action Items** ## **Sept 4th Agenda - General Meeting** | | | | -------- | -------- | | Recording | | | Attending | Radu M, Chris Crone, John Kjell, Matt Butcher, Jeremy Rickard, Carolyn Van Slyck, Glyn N, Ralph Squillace, Urvashi Reddy, Karen Chu | | Note Taker | | **Agenda** - CNAB Core 1.0 vote - https://github.com/deislabs/cnab-spec/issues/142 - is there anything in the discussion about thick bundles that is incompatible with Core 1.0? - https://github.com/deislabs/cnab-spec/issues/242 - display names for actions - action item - Carolyn will open a new issue on localization and internationalization (https://github.com/deislabs/cnab-spec/issues/262) - https://github.com/deislabs/cnab-spec/issues/244 - expected behaviour for multiple invocation images - Chris: multiple invocation images should not have different behaviours, but should be dependent on platform / architecture - Matt Butcher: some label matching could be added, but the core intention was to only address one invocation image - Matt Butcher: I will take a look in the spec to clarify the usage - https://github.com/deislabs/cnab-spec/issues/246 - downgrade installation by running the upgrade action? - Chris: logic lives in the run tool / invocation image, the spec should probably not be too prescriptive - it should be the bundle author's responsibility - Chris: there could be a non-normative section suggesting the UX, but the spec should not be normative - Chris: taking dependencies in account, this would get even more complicated - Urvashi: custom action for downgrade could be helpful, and a clarification to the specification would be helpful - Chris will PR the clarification - clarifications - ready to close? - https://github.com/deislabs/cnab-spec/issues/245 - clarify how outputs are stored in a claim - closing, can be reopened if needed, but it tackles the claims specification - https://github.com/deislabs/cnab-spec/issues/247 - clarification of readOnly in definitions - Urvashi: readOnly and writeOnly are more "notes" and not validation in the JSON schema. - Urvashi will PR the clarification for this issue - https://github.com/deislabs/cnab-spec/issues/248 - clarification of writeOnly in definitions - Carolyn: recommends reading Ryan's comment on how JSON schema deals with writeOnly - Matt Butcher will PR a clarification to the spec - https://github.com/deislabs/cnab-spec/issues/249 - clarification of default in definitions - Urvashi: how to deal with the combination of require and default set on a parameter (user should have no input, and runtimes must evaluate validation) - Carolyn: agreement, however outputs also use the same structure - Carolyn will PR a clarification to the spec - https://github.com/deislabs/cnab-spec/issues/250 - clarify how to convert non-scalar parameters to string - right now we are marshaling them to JSON - if that is not in the specification, it should be, as it is the intended behaviour - canonical JSON solves the issue around numbers - https://github.com/deislabs/cnab-spec/issues/251 - clarification on updating a claim result - related to the claims specification - https://github.com/deislabs/cnab-spec/issues/252 - clarification on stateless actions and installation names - Matt Butcher will PR the spec - https://github.com/deislabs/cnab-spec/issues/254 - clarification of digest validation wording - PR in flight - PR opened, needs review - https://github.com/deislabs/cnab-spec/issues/237 - what happens after a failed install action? - Chris: this should probably be the responsibility of bundle authors, recommend some UX, but the spec should not be prescriptive - Chris will PR a clarification to the spec - wording issues - https://github.com/deislabs/cnab-spec/issues/39 - https://github.com/deislabs/cnab-spec/issues/258 - https://github.com/deislabs/cnab-spec/issues/259 - Matt Butcher and Jeremy Rickard will PR the wording changes to the spec - Matt Butcher: the paperwork for JDF is done, all will be announced on Sept 10, and ideally the spec should be stable by then. Given that most of the changes discussed today are minor, can we do an online vote on Friday for the spec? - Matt Butcher: voting procedure - all core maintainers of the spec are entitled to a vote, a 2/3 majority is needed. Once this passes, it is marked as a recommended draft, then final recommendation. The procedure itself can be open, in Slack, direct messages, or email - a PR would be the simplest way forward. - Jeremy: 2-3 small changes per person - seems doable? - Urvashi: how about the state of Duffle ? - Radu, Jeremy: at this point we validated that all changes required by CNAB Core 1.0 can be implemented in Duffle / cnab-go - Urvashi: agreed - Chris: start moving towards RCs for Duffle / cnab-go - Radu: articles, thanks for feedback - Jeremy: demo for next week ## **August 28th Agenda - Registry and CNAB Security Meeting** | | | | -------- | -------- | | Recording | | | Attending | Jeremy Rickard, Carolyn Van Slyck, Radu Matei, Trishank Kuppusamy, Karen Chu, Matt Butcher, Glyn Normington, Jacob LeGrone, Vaughn Dice, Douglas DePerry | | Note Taker | Carolyn Van Slyck | **Agenda** * New folks * Canonical JSON and the usage of numerical types for JSON schemas (https://github.com/deislabs/cnab-spec/issues/256) * Spec should switch to a customized version of json schema draft 7 using integers instead of numbers * cnab-go should switch from float64 to integer * Updating the OCI Index specification (WIP - https://github.com/radu-matei/image-spec/pull/1) * Can't store decimals in integers, 🤦‍♀️ * Radu will attend OCI weekly meeting and get their advice. * Updates on the security specification * https://cloud-native.slack.com/files/UK3FS1KDK/FMD5USWKV/cnab-security-figure-4.png * Within a single organization, there would be single TUF server. * Developers get automatic delegation, then admin/human goes through and manually claims / verifies the keys for the images later at regular intervals. Same process for bundles. * Single root per TUF server, but each company can have their own root. Consumers can make their own ordered list of trusted roots. * Notary doesn't support having a single root out of the box. * Notary tool doesn't support layers of delegations. * Radu: We should keep a suggested list of common verifications that can be performed on an image/bundle. e.g. extract the file system from an invocation image and check that the run entrypoint * Mark the key management parts as non-normative for now while we focus on the rest of the spec. * Radu: IOU 1 Pager explaining all of this * Pulling invocation images by digest: https://github.com/deislabs/cnab-go/pull/114 * Looks like claims would benefit from the same change (including digest as well) or would be impacted by the change. Jacob will evaluate and address in a follow-up PR. ## **August 21st Agenda - General Meeting** | | | | -------- | -------- | | Recording | | | Attending | Chris Crone, Radu Matei, Glyn Normington, Silvin Lubecki, Jeremy Rickard, {Trishank, Jacob, Doug} (DataDog), Zayd Zori, Ryan Moran, Leah Hanson, Urvashi Reddy, Carolyn Van Slyck | | Note Taker | Radu Matei | **Agenda** * New folks * [CNAB Core 1.0 Specification Freeze](https://github.com/deislabs/cnab-spec/pull/238) * action items: go through the new issues in the spec and see if any of them requires changes * Review recent [issues](https://github.com/deislabs/cnab-spec/issues) * `cnab-go`, `duffle` updates * [`duffle claim show --output`](https://github.com/deislabs/duffle/pull/815) * Are we done with https://github.com/deislabs/duffle/issues/747 ? * is the output issue ready to be closed? * Yes. Will close today if no objections. * we have output handling for the Docker driver. * Duffle already handles this, cnab-go still to implement support in k8s/command drivers. * [Duffle 0.3.1-beta1](https://github.com/deislabs/duffle/releases/tag/0.3.1-beta.1) * new release - is the cadence of releases ok? * Image Digest Validation for 1.0? (related to Distribution perhaps) * no complete implementation of digest validation yet. * the digest field is not populated right now by Duffle (see cnab-to-oci) * create bundle, before pushing the invocation image the bundle is exported - so you don't have a digest yet (no guarantees that the digest from the local demon matches) * Radu: we should have digest validation checks * action item: create issue [in cnab-go] and discuss potential items * Ryan: is there an item in the spec that requires runtimes to validate digests? * action item: create issue [in cnab-spec] and discuss whether to add requirement * [Review the cnab-go 1.0](https://github.com/deislabs/cnab-go/milestone/1) milestone * [Review the Duffle 1.0](https://github.com/deislabs/duffle/milestone/2) milestone * CNAB Distribution Specification * [`cnab-to-oci` updates](https://github.com/docker/cnab-to-oci/pull/65) (relocation map, storing the entire bundle, push / pull in canonical form) * new release (yay) * WIP for storing the entire bundle in the registry instead of reconstructing at runtime * generate relocation maps (both push and pull, consumers can drop both maps) * Glyn: are images copied to the repositories - what is the key of the relocation map? * A: original image * Trishank: how is the bundle actually stored in the OCI registry? * Chris Crone: describes how CNAB-TO-OCI works (storing an OCI index in the registry) * Trishank: making sure that the bundle is not modified when moving to another registry. * Chris Crone: no, bundles are not modified when pushing to a new repo * when to push to get image digests for thick bundles * CNAB Security Specification * [WIP PR](https://github.com/deislabs/cnab-spec/pull/253) (Trishank) * still a WIP * adding a layer of TUF and In-Toto metadata about images and bundles * goal not to tie the spec to a single implementation * gradual security - Trishank describes what the In-Toto metadata is used for + what the TUF metadata is used for * the concept of gradual security allow organizations to gradually implement bundle signature, image signature, then bundle and image provenance * [workflow, metadata used, verification process](https://hackmd.io/@radu/SJHD66H4r) + demo (Radu) * are bundles compressed in the registry? * where should layout signing keys be stored? * Trishank recommandation: use top level delegation * real root of trust should be signed by the top level * potential need for storing data in the bundle for the security spec - use of `custom` from the bundle ## **August 14th Agenda - CNAB Registry and CNAB Security** | | | | -------- | -------- | | Recording | | | Attending | Radu Matei, Justin Cormack, Silvin Lubecki, Urvashi Reddy, Trishank Kuppusamy, Douglas DePerry, Matt Butcher, Jeremy Rickard, Karen Chu | | Note Taker | Jeremy Rickard | **Agenda** - progress update on `cnab-to-oci` pushing the entire bundle and generating the relocation map - https://github.com/docker/cnab-to-oci/tree/relocation-map - Silvin and Radu working on cnab-to-oci - Relocation Map allows unmutated bundle to be stored as a complete thing - Because pushing entire bundle + canonicalized form, always same digest - Content Digest can be checked for bundle and images - Relocation map points to a different repo but same digest - Relocation map injected at runtime to invocation image - Enables an e2e demo (Radu will show at the end) - Nothing changes in OCI index, only changes bundle storing part, no breaking parts - No longer rebuilding the bundle, just pulling as is - Still relies upon annotations on oci index or distribution - Trishank: not reconstructing, just using relocation to pull from own repo - Radu: yes, if any digests don't match relocation, runtimes must error out - Justin: is there a design? - Radu: that's the purpose of this meeting, want to walk through again? - Radu: when you push a bundle, we construct an OCI index, push all referenced images to a repository in reg, then store bundle itself as a blob in registry. BEcause entire bundle stored and canonical, can digest it and all pulls should be the same - Justin: still confused about relocation - Radu: because bundle references image and image includes registry, if you want to move to a different registry, you automatically invalidate the content of bundle if you modify it. If you sign it and move to a registry, and registry generates same digests, we generate at runtime a "relocation map" that points to new location and has content digest, tools make sure digests are the same - Map is generated from existing images in bundle.json and new images in your registry (oci index) - Justin: How is that used at runtime? how does it know what map to generate? - Silvin: when you pull, registry generates it - Radu: only way to ensure that you move things to new registry and not invalidate bundle because image names are part of bundle - Trishank: concerns: 1.) what is our common use case, looks like you're going to trust bundle to tell you where to fetch things. one way to solve is bundle doesnt tell me where to download, just has bundle - Justin: but you need to have image name in order to pull a hash. Not sure if that's strictly needed, the security model says you basically have to prove you have a hash or have auth for a named repo before you pull it, can't make a sha up and magically download contents - Trishank: adding image name doesn't really give you additional security - Justin: no just tells you where to check auth against, someone with same perms as you pushed it so ok to pull it - Radu: I can move an image and not change content digest, can i do that with trust data - Justin: in principal yes - Radu: is this a reasonable approach? - Justin: i think so, it feels weird but i think it's reasonable - Trishank: as long as you don't download the relocation from somewhere random on internet - Justin: it doesnt matter its just telling you where to auth against - Trishank: not silently ignoring digests so thats ok - Justin: hashes will be the same, just re-routing where to get them from. kind of imagine system where we can just have URLs for content hashes and we indirect on how to authorize them - Trishank: use case here is I want to move a bundle from one registry to another (probably private is most common use case) - Justin: would like to think if we can make a more generic mechanism later - Radu: we should start writing this down and getting people to validate - pushing images on `duffle push` - https://github.com/deislabs/duffle/issues/734 - related to how cnab-to-oci does that - silvin: first thing we do is push or mount all images into same repository so we can ref form oci index. has some advantage like guarantee if you can pull oci index, you can pull all images (invo and component images), prevents garbage collection - cnab-to-oci expects things to already be pushed to respective repository, question is: how should tooling handle this? - should tooling push images before or should library that pushes the bundle push them as well? - mutating the bundle on first `duffle push` - adding image digests and size - overview of the security draft (Trishank) - https://github.com/trishankatdatadog/cnab-spec/blob/trishankatdatadog/301/300-CNAB-security.md - see recording for overview of draft + overview of how DataDog uses TUF/in-toto in CI/CD - Time ran short, the PR is open soon. - demo of a proposed workflow for sign -> push -> verify (Radu M) - Radu showed a video, refer to the recording **Action Items** * Triskank can open a PR and we can review it ## **August 7th Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/ZpNmw8R3DbI | | Attending | Ryan Moran, Chris Crone, Jean-Cristophe Sirot, Urvashi Reddy, Glyn Normington, Silvin Lubecki, Jeremy Rickard, Darren (Intel), Matt Butcher, Jacob LeGrone, Karen Chu, Radu Matei, Trishank Kuppusamy | | Note Taker | Radu Matei | **Agenda** * New folks * 1.0 Working Group Approval (https://github.com/deislabs/cnab-spec/blob/master/901-process.md) * Matt Butcher: adopted the JDF working group method of releasing a standard * next phase after WD is a working group approval, where members vote the approval * we want to freeze the core spec at 1.0, and the next step is for the working group to vote * see last week's notes for detailed description of the current state (Duffle) * Glyn: last week we discussed to freeze the spec for arbitrary changes, to allow Duffle to sync * Jeremy: we should freeze the spec, since it's difficult to keep all the tools updated with a moving * Matt: open a PR on the spec to specify we're in a freezing period, so core maintainers decide on whether to freeze it or not. * Urvashi volunteers to open the * Outstanding Duffle issues for 1.0 Core: - outputs: - https://github.com/deislabs/duffle/issues/747 ([open PR](https://github.com/deislabs/duffle/pull/815)) - digest validation (WIP - Jeremy): - https://github.com/deislabs/duffle/issues/233, - https://github.com/deislabs/duffle/issues/391, - https://github.com/deislabs/duffle/issues/392, - https://github.com/deislabs/duffle/issues/393, - core build: - https://github.com/deislabs/duffle/issues/473 ([partial PR](https://github.com/deislabs/duffle/pull/827)) - binary parameters: https://github.com/deislabs/duffle/issues/320 - import / export: - https://github.com/deislabs/duffle/issues/455, - https://github.com/deislabs/duffle/issues/494, - https://github.com/deislabs/duffle/issues/495, - https://github.com/deislabs/duffle/issues/513, - https://github.com/deislabs/duffle/issues/466 (also https://github.com/deislabs/duffle/issues/828), - https://github.com/deislabs/duffle/issues/758 - nil default parameters: - https://github.com/deislabs/duffle/issues/530 * Consolidate outstanding issues for import/export and digest validation * New `cnab-go` release (please review [#82](https://github.com/deislabs/cnab-go/pull/82) and [#85](https://github.com/deislabs/cnab-go/pull/85)) * Jeremy: copying from Linux container with filepath will reconstruct the path on Windows. * after #82 and #85 are merged, new release for cnab-go * New issue on cnab-to-oci [#58](https://github.com/docker/cnab-to-oci/issues/58) about storing the whole bundle.json in a registry * Silvin: please comment on the approach for the issue * Trishank can talk about [using GPG on YubiKeys to sign git commits](https://github.com/DataDog/yubikey) for CNAB tools * signing tags for Duffle releases * https://github.com/DataDog/yubikey * demo of using YubKeys to sign commits * Do we want to outline how runtimes should handle action lifecycle? https://github.com/deislabs/cnab-spec/issues/237 * Ryan: Duffle treats the install action as success/failure. In a failure, it might fail half way through, and you might have to run upgrade next. Runtimes might choose to implement this differently - does the spec outline how runtimes should react? * Chris: docker-app marks failed installation, and uninstall could handle failed installation; upgrade actions could understand failed states, but actual * Darren:if it's in a failed state, the spec should specify how runtimes should handle it. * Matt: is rollback on failure an option? This puts the work on bundle developers * <note taker lost track of the live conversation, check the last part of the recording> * Glyn: what if other actions fail? Should * Chris: agrees with Matt, prescribing too much puts the burden on bundle developers * please comment on the issue ## **July 24 Agenda** | | | | -------- | -------- | | Recording | https://youtu.be/PuotP0cq5-M | | Attending | Jeremy Rickard, Glyn Normington, Silvin Lubecki, Darren (Intel), Radu Matei, Karen Chu, Nuno do Carmo, Urvashi Reddy, Leah Hanson, Ralph Squillace, Ryan Moran, Vaughn Dice, Joao Pedro De Almeida Pereira, Jacob LeGrone | | Note Taker | Radu Matei | **Agenda** * New Folks * Demos? * 1.0 Working Group Approval (https://github.com/deislabs/cnab-spec/blob/master/901-process.md) * But first...https://github.com/deislabs/cnab-spec/issues/229 * Claims, Custom, and Duffle/cnab-go's Relocation Functionality (Jeremy/Glyn) * Stabilizing dependencies for 1.0 (Radu) * Discuss: Validation through implementation (Jeremy) **NOTES** - 1.0 Working Group Approval - Jeremy walks thrhough the approval process document for the core specification - outstanding issue - immutable and readoOnly behaviour for parameters (https://github.com/deislabs/cnab-spec/issues/229) - objections on the approval process: - renaming verbs? - Leah: there is no complete implementation of the spec - should we wait for Duffle to implement all features before 1.0 of the core specification (mainly outputs). - Glyn: there might be an advantage of putting the core spec into draft state, so Duffle can work on a stable version of the spec. - Glyn: there is no compliance test for the spec - Urvashi: we need to know what Duffle lacks from the core specification - Claims and Custom fields - cnab-go has an implementation of the claim that is not part of the specification. Do we need to update the claim definition, or address it in a separate way? (the Claim JSON schema to have a custom field that could be used for non-standard things) - Glyn: are claims supposed to be transported across runtimes? If I install using runtime A, then uninstall using runtime B, should the process work? - Darren: it would be difficult to have claims reused acrossed runtimes - Radu: for relocation (for example) we might need to have a schema - Glyn: if claims are particular to runtimes, what is the purpose of the claim schema in the spec? - Ralph: it could be used to build tools to analyze claims. - Glyn: allow relocation information to go in the Custom section, then promote it as a top-level field - Jacob: use claims similar to how Terraform uses state - pluggable backends, and we're working on an implementation for a claims based API - Ryan: we don't use claims at all, since they are not required. We thought of claims as a way for portability mechanism, but there are gaps in what the claim represents. We have a compliant runtime, but do not use claims at all. - Stabilizing dependencies for 1.0 - strategy: go from the leaves to the top - Jeremy: do we plan to to a release for cnab-to-oci? - Silvin: yes, we plan on doing a release soon. - Bundle dependencies - Jeremy: problem in defining extensions and further specs. Bundle dependencies might be under-specified, and as Porter implements it, it proposes changes back into the specification. Should we have an interim step in the process of proposing specification changes? - Radu: in a previous meeting, we proposed that after 1.0, any change in the specification would have to come with a proposed implementation (should this be Duffle, or any other public tool that implements the specification?) - Jeremy: what about non-core specs? - Leah: for optional specs, it might make sense to allow different tools to validate the implementation - Glyn: maybe it's possible for Duffle to implement every specification. - Jeremy: open a PR to add this - August 15th currently proposed for announcing things - Jeremy: is everyone still happy with a bi-weekly meeting? - everyone agrees **ACTION ITEMS** - please review https://github.com/deislabs/cnab-spec/issues/229 - compile list of items Duffle does not implement from the core specification - use the Custom field in the Claim for now ## **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 Matei, Lachlan Evenson, Karen Chu, 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 ---