--- tags: CDEvents --- # CDEvents Implementation Working Group - Meeting Notes [![hackmd-github-sync-badge](https://hackmd.io/o-vCvOq0SrCq4csB5Bl29g/badge)](https://hackmd.io/o-vCvOq0SrCq4csB5Bl29g) This document contains the notes from the CDEvents Tools and Architecture Working Group. [GitHub Repository](https://github.com/cdevents/implementation-wg) ## Meeting Details ### Schedule - Meetings are held every other Tuesday at [3pm UTC](https://time.is/3pm_in_UTC) during summer time and at [4pm UTC](https://time.is/4pm_in_UTC) during winter time). ### Topics for coming meetings - Review proposal for demo system https://github.com/cdevents/community/issues/31 ### Template Participants: - Name / affiliation / TZ Agenda: - New attendees (Introductions) - \<addme\> ### July 22nd, 2025 Participants: - Ben Powell, Apple, CST - David Bernard, Alchim312/CDviz, UTC+2 - Name / affiliation / TZ Agenda: - New attendees (Introductions) - Merging SIG group suggestion along with changing date/times? - Potential days and times: - Tuesday, 10am CST (same time) - Conduit website in CDEvents - Need to add Conduit information to the CDEvents website. - Add blog - Conduit blog - CDViz blog (potential) - Update adopters - Conference updates ### June 10th, 2025 Participants: - Name / affiliation / TZ - Andrea Frittoli, IBM, UTC+1 - David Bernard - Rajiv Singh Agenda: - New attendees (Introductions) - \<addme\> - CDViz presentation - https://cdviz.dev - https://demo.cdviz.dev ### May 13th, 2025 Participants: - Name / affiliation / TZ - Ben Powell, Apple, CST - David Bernard, -, UTC+2 Agenda: - New attendees (Introductions) - Purpose of the SDK: - Provide API support for CDEvent schemas - Provide a good UX for users to send CDEvents, both core and custom - Provide extensible interfaces, e.g. handler patterns to prep HTTP requests (for example) - Provide high level abstractions over low level generation of APIs/Events - Provide consistency without sacrificing idiomatic target language - Conformance test - Action items - Create a PR with the 4 bullet points for SDK feature list and goals - Ben ### April 1st, 2025 Participants: - Ben Powell, Apple, CST - Vibhav Bobade, Red Hat, IST - Name / affiliation / TZ Agenda: - Vibhav Bobade - Action Items - branch.initialCommit for feature/project/etc (DORA) [GH issue](https://github.com/cdevents/spec/issues/247#issuecomment-2766475627) - How is this event emitted? - pre|post-commit hooks - Having metadata inside of the commit message ``` feature: Add new API /hello --- cdevents: event-type: initialCommit ``` Can also utilize git notes to add metadata Add a special git command, /usr/local/bin/git-cdevent, git cdevent <> Issues with git notes and git commands is high level tools may be problematic - Who sends the events? - User could send the event, but not a good approach due to authentication/authorization - Leaning more towards the SCM service or some webhook adapter that is integrated with the service - For the next-ish spec SIG we need to standardize on this metadata format - AsyncAPI updates - No progress, but more question - How does custom events works in this modeling language in SDKs? - To research the rust language (Ben) - SDK feature parity (circle back in May 1st-ish) - Need to create a doc to define the scope fo the SDKs - \<addme\> ### March 4th 2025 Participants: - Name / affiliation / TZ Agenda: - New attendees (Introductions) - Action Items - \<addme\> ### February 18th 2025 Participants: - Name / affiliation / TZ - Ben Powell, Apple, CST - Andrea Frittoli, IBM, UTC - David Bernard, -, UTC+2 Agenda: - New attendees (Introductions) - Modeling language choice - Smithy updates - Wire format/protocol is handled via plugins - Just not clear what it looks like over the wire - Issues with running Smithy samples - Language specific generation issues: Go and Python - Rust is mixed into the AWS SDK repository - Decided on AsyncAPI - Please review https://github.com/davidB/sandbox_cdevents_spec/tree/main/asyncapi/spec/v6 - Need a document on best practices for schema - e.g. subject needs to be modeled as a component as well as predicates - This allows for duplication across subject to be contained within the subject model - \<addme\> ### February 4th 2025 Participants: - Name / affiliation / TZ - Ben Powell, Apple, CST Agenda: - New attendees (Introductions) - Updates on modeling languages - Today: Tools are difficult to work with - Goal is to start with PKL to rewrite comformance tests (Ben) - Modeling the schema is still to be determined - OpenAPI - Has limitations on what can be expressed - Specifically polyphormism - Issue is more on the side of the tools as opposed to the spec - The reason for this is the spec has a lot of knobs and tools may not support all features that OpenAPI | AsyncAPI provides - AsynAPI may be a better approach - https://www.asyncapi.com - Ben to research - Smithy - Should research this modeling language - https://smithy.io/2.0 - David to research - Updates on naming conventions - Goal is to have this in PR by Friday (Ben) - Updates on CloudEvents verifiability - Proposal has been shipped off to internal security - CloudEvents has been very receptive of our decisions thus far - Once merged into CloudEvents and implemented in the CloudEvents SDKs, CDEvent SDks will need to have ways to enable verifiability - \<addme\> ### January 21 2025 Participants: - Name / affiliation / TZ - Andrea Frittoli, IBM, UTC - David Bernard - Steve Taylor Agenda: - New attendees (Introductions) - Action Items - \<addme\> - Message Service Requirements [PR](https://github.com/cdevents/implementation-wg/pull/4) - To be discussed next meeting - Modeling: - OpenAPI and PKL as possible paths - PKL: meta description to generate what we have today (jsonschemas, examples) - OpenAPI/AsyncAPI/else?: use existing toolset to generate SDKs (or part) and documentation - [AsyncAPI](https://www.asyncapi.com/en) - Smaller community - More focused toolset - David experiment repo: https://github.com/davidB/sandbox_cdevents_spec - Goal is to have one schema for all events - This might require a migration path to be define - Alternatively we could do a breaking change - Toolsets for generation of SDKs would not support multiple versions - [Vector Remap Language](https://vector.dev/docs/reference/vrl/) - ### January 07 2025 Participants: - Ben Powell, Apple, CST - Name / affiliation / TZ Agenda: - New attendees (Introductions) - Modeling considerations choices: - Considerations (Ben): - We can opt to use both openAPI and PKL to their strengths - PKL is good for generating tests, configurations, etc - openAPI is good for generating models for the SDKs - Middleware for massaging to generate non-breaking changes models, but can mark them deprecated, and eventually move completely away from the middleware layer. - Generate both deprecated models and non-middleware models - Goal should be to do away with deprecated models in a few point releases! - GitHub issues to illustrate plan - Issue for PKL - Issue for openAPI - Issue for divergence in openAPI generation versus what we have today - \<addme\> ### 26 November 2024 Participants: - Name / affiliation / TZ - Andrea Frittoli, IBM, UTC - Steve Taylor, DeployHub/Ortelius, MST - David Bernard, -, UTC+1 Agenda: - New attendees (Introductions) - Action Items - \<addme\> - Links available in the go SDK - David: demo using OpenAPI generator for the event part - Code for go, rust, python and Java - Demo of code generation: [davidB/sandbox_cdevents_spec: exploration of other way to define cdevents (and to generate doc, sdk,...)](https://github.com/davidB/sandbox_cdevents_spec) - More API than we have today generated automatically - Bindings, tests still require manual - Breaking changes required for this to work - Handling of version can be a challenge - TBD (David): - Async modular (from async API) - Generalise what is done for the Rust SDK - LFMS CDEvents talk - [github.com/afrittoli/cdevents_interoperability/blob/lfms_2024/cdevents_interoperability.pdf](https://github.com/afrittoli/cdevents_interoperability/blob/lfms_2024/cdevents_interoperability.pdf) - Introduced Implementation WG there - Conferences - David submitted to: - PlatformDay (colocated to KubeCon EU) - Devvox France (in French) ### 29 October 2024 Participants: - Ben Powell, Apple, CST - Steve Taylor, DeployHub/Ortelius, MST - Andrea Frittoli, IBM, UTC - David Bernard, -, UTC+1 Agenda: - New attendees (Introductions) - Modeling language(s) for SDKs: - PKL may not be well suited for SDKs - PKL can generate JSON schema in a more readable fashion - Small demo to show how JSON schema can be generated as well as potentially seeing how it fits into code generation for the SDKs - Next implementation is going to be a PKL demo for generating JSON schema. - Forces consistency across JSON schema - Investigated JSON schema (David) - 1 context class as opposed to many - Breaking change - Polymorphism - Not working properly for Rust - External and internal references - OpenAPI investigation (David) - Use our own templates to generate from - Only use what is limited in each standard library in each language - Currently we have 2 usages of the models: tests and generation - We could potentially generate parts of the SDKs - Demo on this - ?? Reduce to using one version instead of two (Andrea) - Two versions were decided is it felt easier to adopt (Andrea) - Not saying we should not have one version (Andrea) - Potentially massive breaking change !! - Message bus proposal - Comments to talk about adding diagrams, etc (Ben) - What is missing in the proposal? (Ben) - (Andrea) Use case: https://github.com/cdevents/implementation-wg/blob/main/docs/security_automation.md - First item for next WG - (Andrea) Consolidating CDF SIGs / WG - - \<addme\> ### 15 October 2024 Participants: - Ben Powell, Apple, CST - David Bernard, - , UTC+2 - Name / affiliation / TZ Agenda: - New attendees (Introductions) - Generation - Tools - We will split the tooling for investigation - json-schema (today) - model from openapi (json-schema + polymorphism + ...) - message from asyncapi (Ben) - JSON TypeDef: Schemas for JSON optimized for code generation (David) - protobuf IDL (Ben) - smithy (Ben/David) - apache avro - apache parquet - apache arrow - cuelang (David) - pkl (Ben) - hcl - dhall - Action Items - \<addme\> ### 01 October 2024 Participants: - Ben Powell, Apple, CST - Steve Taylor, Deployhub/ Ortelius, MST Agenda: - New attendees (Introductions) - Reviewers needed for [message broker](https://github.com/cdevents/implementation-wg/pull/4) - Need consistent semantic naming: What do we call our message broker? - Will add github issue for semantic naming and we can vote on the appropriate names (Ben) - Should not block PR and could always be updated later - What are the next steps once the broken proposal is merged? - How do we go about implementation? - What technologies (existing brokers)? - Language choices? Etc. - Start with a closed approach first - [Modeling language for SDKs](https://github.com/cdevents/implementation-wg/issues/5) - Solutions for systems/companies to start using CDEvents - Active Solution - Company, like GH, fully implements a CDEvents producer - Middleground - Webhook adapter - Passive solution - Some polling system that creates CDEvents - Will add this talking point in the spec SIG to stir the pot - \<addme\> ### 20 August 2024 Participants: - Ben Powell, Apple, CST - Steve Taylor, DeployHub/Ortelius, MST - Jalander Ramagiri, Ericsson Software Technology, UTC+1 - Adam Kenihan, Ericsson Software Technology, UTC+1 Agenda: - New attendees (Introductions) - Translators for webhook adapter PRs: - https://github.com/cdevents/gerrit-translator/pull/3 - https://github.com/cdevents/jira-translator/pull/1 - Draft Messaging Updates: [CDEvents Message Service Requirements](https://docs.google.com/document/d/15KkXLWK3OcQ0V5GHluZ21tifSSD4DKmxQKkDXeWx-d8/edit?usp=sharing) - Should we include persistence in the design of the message bus? - (Ben) Database should not be the focused, but should be at least mentioned and pluggable into the message bus system. - Is the doc specific to message bus design or a service that contains more than just the message bus? - CDEvents visualization with Prometheus/Grafana tool - PR: https://github.com/cdevents/visualisation/pull/3 - \<addme\> ### 6 August 2024 Participants: - Name / affiliation / TZ - Andrea Frittoli, IBM, UTC+1 - Steve Taylor, DeployHub/Ortelius, MST - Jalander Ramagiri, Ericsson Software Technology, UTC+1 - Ben Powell, Apple, CST - David Bernard, Wefox/Vector8, UTC+2 Agenda: - New attendees (Introductions) - Action Items - \<addme\> - (Steve) Draft Messaging Requirements: [CDEvents Message Service Requirements](https://docs.google.com/document/d/15KkXLWK3OcQ0V5GHluZ21tifSSD4DKmxQKkDXeWx-d8/edit?usp=sharing) - Steve to accept minor comments - Review major comments in the next meeting - Should signing of events be included here? - Ben: working on signing of events at CloudEvents level to make the event verifiable - (Andrea) Use Case document - https://github.com/cdevents/implementation-wg/pull/3 - ok to merge and iterate? - Steve to review, ok to merge now and we can iterate - David: ok to merge now and iterate, there are many open points - Some overlap with the project David is working on, which is focused more on the visualization side of things - (Andrea) Go SDK - OK to make a release? There's some follow-up to be discussed - Parts of the API need to be more idiomatic - Changes would be backward compatible - additive changes - (Andrea) GitHub Webhook Adapter - https://github.com/cdevents/webhook-adapter/issues/2 - Hergy is interested in contributing to this - Tentative Plan: - Identify events and mappings: - Ben: we should have proposal document - Create a new repo for the plugin - Implement the plugin - It would be interesting as a follow up to investigate running the webhook adapter as the backend side of a GitHub app - If the translation layer can be reused ~SDK like, we could reuse it in a GitHub app - Ben to prepare a proposal about this - David: there is a similar component `cdviz-collector` in the [cdviz project](https://github.com/davidB/cdviz) - (Andrea) Yousuf Jawwad, founder of Quantm.io, reached out to me and then on slack - The CDEvents idea resonates with them and they are interested in contributing to CDEvents - They'd be interested in a GitHub adapter as first step - Yousuf also asked about the possibility of being sponsored to contribute - I asked Henry to sync with them about the GitHub adapter - Share the proposal document - we need the GitHub alias - Andrea on holidays 8/8 till 28/8 - (David) Would like to make a release of the Rust SDK v0.4.1 - David to make the first publishing of the SDK - SDK tested against examples and schemas, for each version - (Ben) Verifiability proposal still ongoing - Ben working on the proposal ### ~~23 July 2024~~ Cancelled! ### 9 July 2024 Participants: - Name / affiliation / TZ - Andrea Frittoli, IBM, UTC+1 - Ben Powell, Apple, CST - Steve Taylor, DeployHub/Ortelius, MST Agenda: - ~~New attendees (Introductions)~~ - Action Items - (Andrea) Create repo: [GitHub Repository](https://github.com/cdevents/implementation-wg) - (Steve) Draft Requirements: [CDEvents Message Service Requirements](https://docs.google.com/document/d/15KkXLWK3OcQ0V5GHluZ21tifSSD4DKmxQKkDXeWx-d8/edit?usp=sharing) - Ben and Andrea to review / update the doc - Requirement docs for the messaging side - (Action) Andrea: setup a root document, like table of content for other docs, with intro, architecture and link to the component specific docs - WIP: https://github.com/cdevents/implementation-wg/pull/3 - (Andrea) What do we want to achieve in the upcoming meetings? - Proposal - could map that to a GitHub project - Identify a use case we want to solve via CDEvents - Include specific requirements - Draw the technical architecture we want to use to achieve that - Perform gap analysis: what's missing - What we should focus on implementing - Who's doing what - Mermaid for diagram - Start implementation - Setup infra (Terraform, Ansible?) - Add components as they are implemented - Live instance in some team playground? - Iterate - Experiment, see what's missing, prioritize work - (Andrea) SDK work - Golang SDK and custom events demo - Examples: we should align examples across languages - Java, Rust, Python? - (Andrea) Reach out to Jalander and David about this - (Steve) Is there an OpenAPI like spec for pub/sub or CloudEvents - [asyncapi](https://www.asyncapi.com/en) might be an option - (Ben) Review Java SDK (In Progress) - PR to be reviewed https://github.com/cdevents/sdk-java/pull/83 - (Ben) Review Jira Translator RFC (In Progress) - (Ben) Writing Links issuein the implementations WG repo (In Progress) - \<addme\> - Next meeting Steve on PTO ### 25 June 2024 Participants: - Name / affiliation / TZ - Steve Taylor, DeployHub/Ortelius, MST - Tracy Ragan, DeployHub/Ortelius, MST - Andrea Frittoli, IBM, UTC+1 - Ben Powell, Apple, CST - Jalander Ramagiri, Ericsson Software Technology, UTC+1 Agenda: - New attendees (Introductions) - Action Items - (Steve) [Draft WG Mission](https://docs.google.com/document/d/1RgROt_MRep81bQp2qZ2HgZKG3tce7DHRUHhY2WscJts/edit?usp=sharing) - Facilitators Rota - Ben - Andrea - Communication & Tools - Use existing Slack channels - keep larger audience - No new communication channels for now - Working Group Name and Mission - [Draft WG Mission](https://docs.google.com/document/d/1RgROt_MRep81bQp2qZ2HgZKG3tce7DHRUHhY2WscJts/edit?usp=sharing) - Reviewed the document, comments added directly to google doc - (Action) Create the initial repo for documentation - Andrea - (Andrea) CDEvents Playground (Create GitHub issue) - GitHub app - Ability to chain message brokers. Idempotency? - (Andrea) How do we get more people involved? - Ben: identify companies already considering CDEvents implementation - Companies - Fidelity - JP Morgan - SAS? - OpenSSF - They are having trouble getting the security tools adopted - CDEvents can help with it - FinOS - Tracy: - Fine to start with a small group - Let's define initial use cases and architecture to make it interesting for people to contribute - \<addme\>