# 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 ## Feb. 19th - General Meeting | | | | -------- | -------- | | Recording | | | Attending | Silvin Lubecki, Carolyn Van Slyck, Radu Matei, Chris Crone, Jacob LeGrone, Vaughn Dice, Ben Whiting, Ralph Squillace, thomhane, Karen Chu, Trishank Karthik Kuppusamy | | Note Taker | Carolyn Cnabby Van Slyck | ### Agenda - Welcome new CNABBERS 🦀 - (delayed as no butcher is here) Vote on [cnabby the crab](https://cloud-native.slack.com/archives/CEX1W7WMD/p1581531593127100) as our official autocompletion mascot - CNAB registry spec (Chris Crone/Docker) - CNAB Security (Radu M) - moved Signy to [`github.com/cnabio/signy`](https://github.com/cnabio/signy) - need formal core maintainers - ongoing Notary v2 discussion - gathering requirements in [this repo](https://github.com/notaryproject/requirements) - (carolynvs) Question: When we bump the spec, e.g. 1.0.1, what is the expected behavior for a tool, maybe an older version of a tool, when it loads a bundle that targets 1.0.1 and the tool was written for 1.0.0? Or other variations? - Governance: - Factorize or add template of the governance description at organization level - Update rules to better fit with the current process - Standard governance, contribution guidelines, (maybe developer guide?), code of conduct reference for all repositories (Radu M) - re-upping [#285](https://github.com/cnabio/cnab-spec/issues/285) to think about where that is - cnab-spec PR reviews: - https://github.com/cnabio/cnab-spec/pull/331 (vadice) - https://github.com/cnabio/cnab-spec/pull/330 (vadice) - add'l: https://github.com/cnabio/cnab-spec/pulls (handful from Butcher) - example bundles in duffle repo: https://github.com/cnabio/duffle/pull/888 - CNAB to OCI call for maintainers (Chris/Silvin) - KubeCon EU (Chris) - Action field to top level in claims: https://github.com/cnabio/cnab-spec/issues/328 (Jacob) ### Notes * delayed vote on cnabby because Butcher is sick * Chris: write down as part of the spec how we store bundles using cnab-to-oci, looking for volunteers. Will discuss further on the off-week meeting (registry/security) with help from Radu and DataDog. * Radu: How do we want to propose the work for the new media type? It's been proposed by Radu to OCI months back and pushed back on. (ded 🦀) Ralph will help revive with a hammer. * CNAB Security (Radu M) * Moved signy to cnabio 🎉 * Looking for more maintainers/codeowners, even if you are new to the security spec. Radu will help mentor. * We need to write docs, and Radu has been identifying other low-hanging fruit. * Open discussion/issue with registries about notary v2, gathering requirements especially around airgapped scenarios. Want to present to them what we need for CNAB. * Pause to make fun of Ralph. * Should tools that targeted older patch versions of CNAB support newer patch versions of CNAB? * (carolynvs) We should open an issue to discuss forward and backward compatibility behavior and update the spec to clarify. https://github.com/cnabio/cnab-spec/blob/master/901-process.md#versioning * We have noticed drift in some of our governance and community docs that we copy between all of our repos. Instead of copying between all of them, let's get a common copy that it is up to date in the community repo, and link to them. Then open a PR to discuss changing them to match how we really operate today. carolyn (make issues), radu, silvin to follow-up (rubber-stamp brigade) * Declartive Installation Support (https://github.com/cnabio/cnab-spec/issues/285) Zombie Issue 🧟‍♂️ * Ralph will schedule a one-off meeting with interested people to discuss this further and split off issues from it since it's pretty far ranging. * Please review * https://github.com/cnabio/cnab-spec/pull/331 - Use https in our schema refs * https://github.com/cnabio/cnab-spec/pull/330 - Use regex that works with go * https://github.com/cnabio/duffle/pull/888 - Move example bundles from separate repo into duffle * After 888 is merged, we will deprecate the example-bundles repo. * Discussed consumers of the example bundles and agreed that they are useful for us, people who work on the spec and tools that work with the spec. They aren't targeted for people who are learning how to write bundles. Ralph will write up text that explains this so that people don't stumble on them and are confused. * cnab-to-oci is also looking for contributors and maintainers! 😎 * (Ralph) We should look at Josh Dolitski's work with the OCI registry validator to think about if this could work well for CNAB to also check if registries are CNAB (cnab-to-oci) compatible. * https://github.com/opencontainers/distribution-spec/tree/master/conformance * https://oci-distribution-conformance-results.s3.amazonaws.com/dockerhub.html * Chris has a talk at KubeKHAAAAAAAAN! Let him know if you have cool CNAB stuff that should be mentioned * There will be meetings about notary and oci. * We want to setup a cnab meeting, Ralph will help figure out how to get a room. * https://github.com/cnabio/cnab-spec/issues/328 - move action to a top level claim * Radu, Jacob and Carolyn will make a draft for splitting result from claim and make sure we are happy with how we are representing claims (this is all related to perhaps using claims to do too much) ## Feb. 13th - Security and Registry Meeting | | | | -------- | -------- | | Recording | Radu Matei | | Attending | Radu Matei, Trishank Karthik Kuppusamy, Jacob LeGrone | | Note Taker | Trishank Karthik Kuppusamy | ### Agenda - Trishank - Busy hax0r1ng signy to improve default key management - Radu: yes, there's room for improvement in the Notary v1 model, but we need to be cognizant of being able to reuse Docker Content Trust keys for those who want that. - Radu - Moving signy to cnabio this week - Jacob - Have you seen [this issue](https://github.com/cnabio/cnab-spec/issues/285)? - What is the plan for maintaining a list of blessed (say, invocation) images? - Radu: Notary supports [pinning roots of trust](https://docs.docker.com/engine/security/trust/content_trust/#enabling-dct-within-the-docker-enterprise-engine), so we can choose to trust only these images. We can either distribute these roots of trust in GitHub (Trishank), or maintain a separate OCI index where we update them using an indirect root of trust. - Jacob: what's the plan for verifying images in an unsigned bundle? (Radu and Trishank: we can use Docker Content Trust for that.) We will need multiple layers of verification, especially when CNAB workflows enter the picture (workflows->bundles->images). Might want an optional paranoid mode where we must verify signatures on bundles and/or images (Trishank). - Jacob: what about airgapped environments? How do we transmit signed bundles? Maybe a thick bundle shipped along with signatures in a tarball? Radu: maybe you can maintain separate Notary and Registry services in each environments, and sync state every once in a while in a trusted manner. Trishank: Notary supports [ignoring expiration](https://docs.docker.com/engine/security/trust/content_trust/#using-dct-in-an-offline-environment) in offline environments. - Next steps: - Radu will take a lot at signy issues end of this week or early next week (especially the Registry self-signed TLS root cert issue) - Jacob and Trishank will pair-program and hax0r signy, they will get back with issues, lessons, and recommendations ## Feb. 5th - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/O7x4Y-heWZo | | Attending | Carolyn, Matt Butcher, Vaughn Dice, Ralph, Nuno, Silvin, Karen Chu, Radu, Somansh, Jacob LeGrone | | Note Taker | Radu Matei | ### Agenda - Welcome new CNABBERS 🦀 - (carolynvs) Demo Porter saving host environment remotely and injecting secrets from Azure Key Vault - Registry and Security updates - `cnab-to-oci` moved under the [`github.com/cnabio/cnab-to-oci`](https://github.com/cnabio/cnab-to-oci) GitHub organization 🎉 - security spec drafts merged into `master` 😎 - feedback welcome - Go implementation for the security spec (`signy`) PR to move under `github.com/cnabio` ([PR](https://github.com/engineerd/signy/pull/42)) - [spec issue #319](https://github.com/cnabio/cnab-spec/issues/319) - Standardize spec version layout and use versioning per described process - CNAB Core 1.0.1 discussion (and possible vote) - Do we hold until this is fixed? https://github.com/cnabio/cnab-spec/issues/316 ### Notes - Introductions (again) - Nuno - Carolyn demos Porter - saving host environment remotely and injecting secrets from Azure Key Vault - Porter and `cnab-go` changes required to make this work - Radu: How difficult is it to add a different source for storage and secrets? - in Go it is pretty simple, used quickstarts for various clouds - the CRUD store interfaces are already defined in `cnab-go`, so in Go you have to implement the interfaces to read/write to/from your source - ideally, we could work the plugins generically enough so any CNAB implementation would use them - for other languages, implement RPC (not gRPC) - look into examples from Hashcorp plugin-go - make a binary / executable that implements the Go RPC interface - Matt Butcher: are plugins long-running? (external plugins) - Carolyn: no, there is a connection that is closed after the one operation is performed, but you can manually specify the connection to be kept open - Butcher: are there any concurrency issues if you are running multiple Porter instances that read/write to the same store (storage container)? - Carolyn: you do have to have something that is capable of acquiring a lock on a given resource so you don't concurrently try to change the same resource - Jacob: there is an opportunity to add X providers (secrets, paramters) into `cnab-go` so implementations could retrieve them directly from `cnab-go` - Carolyn: next step is to use the same model for paramters - Jacob - do we need a separate interface for retrieving paramters? (more complex validations, for example) - Ralph: let's create some concrete user stories to really understand how much more complex the paramter validations are for this scenario - Carolyn: since we have this issue both in Porter and at DataDog, I think this is a real problem - Jacob: I already have an interface for this, I could share it and see if it needs any modifications - Carolyn: Great, share it! - Jacob: it makes sense to have interfaces for getting credentials, paramters, claims. There is an issue with the driver interface where if you instantiate multiple driver instances, the driver has to recreate the claim from the operation object, which might need refactoring. Right now I have an API that is backed by the Kubernetes driver, so I have to reconstruct the claim on the API before talking to the actual Kubernetes driver implementation - Moving `cnab-to-oci` to `cnabio` - Silvin: yesterday we transferred the ownership of `cnab-to-oci` from Docker to `cnabio`. We asked JDF the requirements - only a few commits that were not signed off, we added a DCO bot to the repository. - Matt Butcher: great news! - Radu: we want to move `signy` as well - Butcher: also ask Chris Chrone - Possible vote for CNAB Core 1.0.1 - there is one issue (316) that could result in uncertainty - we should hold off on voting until after this issue is resolved - issue 319 - 3 parts to the request - explain how the documents in the spec repo relate to each other - bring the state of the files in the repo up to date with ^^ - standardize the way we represent versions - Ralph: the context is that a larger org is looking into understanding the spec, and they don't - Matt: even formatting change will have to be formalized - next week - more interfaces into cnab-go and other language libraries - hopefully call a vote for core ## Jan. 29th - Security and Registry Meeting | | | | -------- | -------- | | Recording | | | Attending | | | Note Taker | | ### Agenda - security spec - merged [draft PR](https://github.com/cnabio/cnab-spec/pull/280) for section 303 (verification workflows) - drafts PRs for sections [301](https://github.com/cnabio/cnab-spec/pull/281) and [302](https://github.com/cnabio/cnab-spec/pull/282) need rebasing - move [`signy`](https://github.com/engineerd/signy/pull/42) and [`pysigny`](https://github.com/engineerd/pysigny/pull/13) to `github.com/cnabio` ## Jan. 22nd - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/88fBb78H_oU | | Attending | Jacob LeGrone, Matt Butcher, Radu Matei, Ralph Squillace, Carolyn Van Slyck, Vaughn Dice, Chris Crone | | Note Taker | Carolyn Van Slyck | ### Agenda - Add Silvin as core maintainer for the spec - https://github.com/cnabio/cnab-spec/pull/315 - Formalize Claim fields - https://github.com/cnabio/cnab-spec/pull/309 (Matt) - Clarify contentDigest - https://github.com/cnabio/cnab-spec/issues/287 (Jeremy) - Mounting the previous bundle on upgrade actions (Silvin) - https://github.com/cnabio/cnab-spec/issues/296 - Store a claim when an action has state (Carolyn) - https://github.com/cnabio/cnab-spec/issues/312 - Call to vote on new version of CNAB Core 1.0.1 ### Notes * Approved Silvin as a spec maintainer * Discussed claims comments on the PR * Do we store state (e.g. terraform state) in the claim? In custom? Next to the claim? * Jacob suggested that bundles can specify which outputs they want mounted inside the bundle for upgrade and not be stored in the claim anymore. * Carolyn add non-normative section to use outputs as state as well (instead of custom). * Jacob: Can we remove the rest of non-declarative info from the claim so that we can make an index on the claim? Hard to do that now properly because of previous action, underway status, etc. * Yes! 💯 * Jacob will open PR to move outputs of claims * Carolyn will open PR to split claim into claim (declarative) + audit log with the result of previous actions * Mounting the previous bundle on upgrade actions * Mount a directory of claims/revision by uuid? * Last sucessful claim mounted only is easiest for now until we have a use case * Is there value in being able to restart an action using the last failed claim, e.g. repeating a failed upgrade and getting back the state/claim from that failed upgrade so that it can start from where it left off or clean up? * Possible answer is that tools solve this and can pass in a different claim. * Call to vote on new version of CNAB Core 1.0.1 * This would be a patch bump of the spec * Errata is for spelling and grammar * master is a draft, a pit for us to review not an immediate version bump - so say we all ## Jan. 15 - Security and Registry Meeting | | | | -------- | -------- | | Recording | https://youtu.be/VwwJ8lYVIFM | | Attending | Radu Matei, Matt Butcher, Chris Crone, Trishank Karthik Kuppusamy, Karen Chu | | Note Taker | Trishank Karthik Kuppusamy | ### Agenda - Bundle formats as part of the core spec and relationship to registries and security (https://github.com/cnabio/cnab-spec/blob/master/104-bundle-formats.md) - Notary V2 scenarios and requirements (https://github.com/SteveLasker/notary) - Walkthrough of security spec PRs: [#301](https://github.com/cnabio/cnab-spec/pull/281), [#302](https://github.com/cnabio/cnab-spec/pull/282), and [#303](https://github.com/cnabio/cnab-spec/pull/280) - Moving security implementations into `github.com/cnabio` and discuss next steps ### Notes - Bundle formats - Radu: clarify in Slack - Matt: can we have a formal process where someone like myself can verify and vouch that CNAB-Sec is compliant with CNAB-Core? - We can keep the process light by nominating one person in a team to make sure their changes are interoperable with other teams - PRs - Let's get 301-304 reviewed and merged as first _working draft_ - Trishank will circle back to 300 later - Matt, Chris, and others will review in the next 1-2 weeks - Radu and Trishank should make as much progress as possible with 300 in the same time frame - People are not likely to read external specs, so let's try to explain as much as possible - Notary v2 - Radu will track their work to see how it will impact us in the future - CNAB-Sec 1.0 will target Notary v1 - CNAB-Sec 2.0 might target Notary v2 - Trishank: add uses cases to Notary v2 (note to self) - Implementations - Can we vote to move signy (Go) and pysigny (Python) to cnabio? - Chris: we should merge them so that they are visible - Radu: Go version is more advanced than Python right now, and the README makes clearly we are still in WD - Action items: we should start testing whether signy works with duffle / cnab-go - Transfer knowledge of Datadog use cases to signy and also Notary v2 ## Jan. 8 - General Meeting | | | | -------- | -------- | | Recording | https://youtu.be/bsDOqRCzhzM | | Attending | Ralph Squillace, Radu Matei, Matt Butcher, Chris Crone, Trishank Karthik Kuppusamy, Carolyn Van Slyck, Silvin Lubecki, Jacob LeGrone, Vaughn Dice | | Note Taker | Radu M | ### Agenda - Add Silvin as maintainer on Spec repo (Matt Butcher) - _Stable_ working draft for CNAB Security and Distribution (when ready) vs. 1.0, considering upcoming changes with OCI Artifacts and Notary v2 (Radu M) - Move other repositories (e.g. `signy`, `cnab-to-oci`) under github.com/cnabio (Radu M) - Please review the latest PRs on the security and claim specifications (https://github.com/cnabio/cnab-spec/pulls) (Radu M) - Common repository for `cnab-to-oci` C bindings? (Rust and Python bindings in progress) (Radu M) - Claims spec process to completion (Matt Butcher) - Update on MS usage of CNAB and Porter (Matt Butcher) - Should we parse digest from the `image` field? https://github.com/cnabio/cnab-go/pull/166 (Jacob) -- see also https://github.com/cnabio/cnab-spec/issues/287 - Anyone working on a distributed claim store? (Chris) ### Notes - Add Silvin as maintainer on Spec repo - we voted last November to add him, but the configuration to the repo was not added - Stable draft vs. 1.0 for security and registry - Chris: if we wait for registries to support new versions, it might take a long time. Notary work is unknown at this point. - Trishank: not sure if there will be incompatible changes for Notary, so we don't know at this point. We should release a 1.0 with the stable draft, then update if / when new versions are supported. - Matt: do we anticipate changes to the core spec? - Radu: we could end up with different versions - Chris: I worry that if we don't cut versions, people trying to adopt will be deterred because they will think we don't have stable versions. - move other repos to `cnabio` - Matt: switch to DCO for all repos (JDF) - Chris: `cnab-to-oci` has to go through legal first, but it needs to vetted first - Matt: we should also move `signy` to have an _official_ implementation for security as well - there might be a change to the core spec that would require an errata - claims spec - Matt: I would like to push the claims spec to completion spec, as multiple tools use it already - Matt: there is an outstanding requirement to change `name` to `installation` that might break existing tools. - Matt: strive to have the claims spec in a stable draft by end of February - Ralph: does the spec have any statement that would prevent storing state in claims, or does it need changes? - Matt: we have a statement that would allow an opaque data storage for systems like Terraform - Carolyn: have we been thinking about tracking the actions that have been performed on a bundle besides the last one, like an audit operation? - Matt: I don't think there is anything specific on it, I will look at it carefully - but because a claim has a name and revision ID, it should be trivial to retrieve all claims related to a bundle - Carolyn: distinction between something we implement vs. something required of all tools - Jacob: I have been working on an API that queries all claims for a specific bundle - Chris: Jacob, could you share that API? It is something that Docker App also needs to solve - Jacob: I would like to switch the API to protobuf and at least share the proto - I want to open source it, it might take some time - Carolyn: is it for claim storage? - Jacob: the API handles installations and internal workflows, for storing, querying, distributing instalations - Carolyn: I've been working on a plugin for claims backends for tools (Porter, Duffle) to use and store claims in backends - it would be nice to collaborate - Jacob: I could do a demo (add as agenda) - Matt: if there are changes required in the claim spec to enable distributed claim stores, please - Jacob: add an identity to claims for audit purposes - we explicitly stated that we don't handle this in claims right now, but this might be required, as we're currently storing that outside the claim - Matt: could you open an issue for this? This will end up being required most probably. - update on MSFT usage of CNAB and Azure examples - Ralph was supposed to present this (existing Azure examples have been migrated to CNAB, and the Azure Docs team started implemented bundles) - Should we parse digest from the `image` field? https://github.com/cnabio/cnab-go/pull/166 (Jacob) - Jacob: context in PR linked above, more opinions are very helpful here. The PR introduces a `Digest()` function for images - should the method return the content digest, return it only if it was added in the bundle, or return it from the image - Jacob: there is also a question of what the content digest is in the context of Docker images - please check the discussion and comment. - Matt: we should re-document and add this again on the agenda for next time. ## Dec. 11 Agenda - General Meeting | | | | -------- | -------- | | Recording | https://www.youtube.com/watch?v=947TG3yDogw | | Attending | Matt Butcher, Radu Matei, Silvin Lubecki, Glyn Normington, Vaughn Dice, Karen Chu, Jacob LeGrone, Chris G, Ralph Squillace | | Note Taker | Matt Butcher | ### Agenda - Intros and Announcements - Demos - Status on Claims spec (Butcher) - This needs one more review: https://github.com/cnabio/cnab-spec/pull/295 - A claim should have a reference to the bundle https://github.com/cnabio/cnab-spec/issues/297 - Upgrade action should mount the previous bundle https://github.com/cnabio/cnab-spec/issues/296 - Clarify terminology: https://github.com/cnabio/cnab-spec/issues/298 - Status on Security and Registry specs - Coordination: Are there any release announcements in the next 2 months? (Butcher) - Holiday Schedule ### Notes: - Demos - Notes: Radu shows generating Rust bindings for OCI registries pulls by bridging Go (via CGO) and Rust (via bindgen) and dynamically loading the library. His demo showed pulling a CNAB bundle.json from Rust using this. - Q (Jacob): Did we talk about storing the bundle.json itself instead of a pointer to a blob? - A (Radu): I think CNAB-to-OCI used to do this, but we lost the content digest when we did that because we don't know how the registry will store it - Q (Glyn): It may be worth wrapping the unsafe, bindgen-generated interface to cnab-go in rich Rust types. - A (Radu): Yes, this demo was just getting a simple case working. - Q (Glyn): Is the Go runtime loaded each time? - A (Radu): Not sure, but probably - Q (Jacov): do people want to see a demo of how we use bazel to construct the digests prior to pushing? - A (Glyn): it's likely that you have an unintentional expectation that docker compression will remain the same, so look out for that - A (Radu): love to see Jacob's demo however - Q (Radu): How do we package shared objects in binary releases? - A (): - Status of Claims Spec - #295 needs another lgtm - #296, #297 Butcher to take another pass at them - Some verbiage still needs clarification - Next meeting would be great to lock this small spec area down; really only tidying is required - Anything else should be in here? - Q (jacob): what is your definition of a release? - A: an installation of a claim; an ugrade is a "release" of an installation, but releases aren't tracked in the spec but installations are. The language got muddied; perhaps we just eliminate one term altogether. Jacob: I think we just need "installation" and not release. Agreement: Butcher/Glyn. don't want confusion with things like helm, too. - Jacob: PR for cnab-go that just needs a review: #165 - Radu: Do we want to change the import paths for cnab-go and duffle? - A: Jacob: I updated for cnab-go - A: Go ahead and upgrade duffle - Status of security spec - Ralph: Trishank is still strongly motivated to move it to completion - Radu: There is a Go implementation with CNAB-to-OCI and Notary. Started a Python implementation. The FFI work might also work with Python sharing with Rust(?). Technically, all the pieces are there and functional - Status of registry spec - OCI blocking issue #1: Index has no concept of a config object. No way to add a type to an index (e.g. a CNAB type) - OCI blocking issue #2: All images referenced in an index must be part of the same registry as the index. No way to include references to remote objects (e.g. like part of a different repo) - Issue is really storing multiple types in the same repository, not necessarily referencing external artifacts. The conversation in OCI is all wrapped up together. We don't need the external references, though... just multiple types in the same registry. - Discussion about cyclic dependencies, garbage collection re: external references - Any upcomming announcements? - No big ones - Holiday Schedule - Next meeting will be January 8, 2020 - Renaming libcnab-rust repo to cnab.rs - Add Jacob Legrone as a maintainer (Radu) - Create issues for the next three: - Then we can do the GitHub rename - Cut some releases - Add GitHub action for running tests ## **Nov. 13 Agenda - General Meeting** | | | | -------- | -------- | | Recording | https://youtu.be/aagxX3Qq1WI | | Attending | Matt Butcher, Carolyn Van Slyck, Jacob LeGrone, Karen Chu, Glyn Normington, Andrew Stringer, Radu Matei, Ralph Squillace, Vaughn Dice | | Note Taker | Carolyn | ### Agenda - Intros and Announcements - Demos? - The State of the Claims spec (Butcher) - libcnab-rust (Butcher) - [Make status.json a CNAB Output](https://github.com/deislabs/cnab-spec/pull/290) - CNAB Registries and CNAB Security (Radu M) ### Notes - The State of the Claims spec (Butcher) - Butcher takes the lead on getting the claims spec going again. - Sufficiently vague so that the tools can move around their home dirs without hating on the spec - libcnab-rust (Butcher) - restarted work on the Rust library - anyone opposed to having a full runtime in Rust? - Suggestion to split out library and client/runtime so that people can consume it like we do cnab-go - Ruffles repo! - Need integration tests across both to ensure we have the same outputs - [Make status.json a CNAB Output](https://github.com/deislabs/cnab-spec/pull/290) - Hearty 👍 all around - Security Spec Update - Spec: working on recommendations - Need people who know python to help with implementation