Skip to content

Latest commit

 

History

History
1634 lines (1348 loc) · 61.4 KB

working-group-notes-2022.md

File metadata and controls

1634 lines (1348 loc) · 61.4 KB
Raw
tags
CDEvents

CDEvents / Vocabulary Discussion Meeting Notes 2022

Archived

This document contains the notes from the of the Events SIG meetings focused on vocabulary discussion.

The Tuesday meetings are held at 3pm UTC during summer time and at 4pm UTC during winter time), and the Wednesday meetings are held at 10am UTC during summer time and at 11am UTC during winter time).

Dec 19th

Participants:

  • Emil Bäckmark, Ericsson, UTC+1
  • Andrea Frittoli, IBM, UTC
  • Erik Sternerson, dowhile, UTC+1

Agenda:

  • SIG Events meeting

    • Presentations
    • Interactions for other SIGs
    • Event architecture
    • Held on demand (if there is an agenda)

  • Holiday meetings

    • Jan 2nd SIG Events, CDEvents Cancelled
    • Dec 27th CDEvents Cancelled
    • Next CDEvents WG Jan 10th
    • Next SIG Events meeting (if agenda) Jan 16th

  • New timeslot for APAC friendly meeting since today

  • (A) Andrea to track TOC presentation feedback in an issue

  • v0.2 planning

Dec 13th

Participants:

  • Andrea Frittoli, he/him, IBM, UTC
  • Emil Bäckmark, he/him, Ericsson, UTC+1
  • Erik Sternerson, he/him, doWhile, UTC+1

Agenda:

Dec 7th

Participants:

  • Andrea Frittoli, he/him, IBM, UTC
  • Emil Bäckmark, Ericsson, UTC+1
  • Mattias Linnér, Ericsson, UTC+1
  • Brad McCoy, he/hime, Basiq, UTC+10

Agenda:

  • Meeting time

    • Current time on Wednesday is a permanent conflict for Erik
    • Alternatives (proposed by for Erik). Please vote with +1
      • Tuesdays at the same time or
      • Tuesdays one hour earlier +2
      • Wednesdays one hour earlier +2
      • Wednesdays one hour later +2
      • Thursdays one hour later +1
      • Fridays almost any time
    • Andrea to make a Doodle
      • Ping Vibhav, Adam, Jalander, Salaboy, Hergy Tchuinkou, Christoffer Vig

  • CDEvents presentation to TOC

    • Surface POC / videos on the website
      • Showcase CDEvents
      • Robert can help
    • Provide a top 3 list of things CDEvents needs help with
      • Maintain a list at all times
      • TOC can help advertise how to contribute to CDEvents
    • Slides

  • TOP three priorities (good candidates for new contributors)

    • Help with Java SDK

    • Help with Python SDK

    • Revamp POCs

      • Port existing POC to v0.1
      • Move to CDEvents GitHub org
      • Document on website

    • Other priorities, probably not good for newcomers

  • Connecting events

  • Release Events

Nov 29th

Participants:

  • Andrea Frittoli, he/him, IBM, UTC
  • Emil Bäckmark, he/him, Ericsson, UTC+1
  • Fatih Degirmenci, he/him, CDF, UTC+1

Agenda:

  • Actions

    • Andrea to draft incident events
      • Ongoing
    • Ben to create an issue about "global ID"

  • CDEvents website & docs updates

    • Aiming to complete the bulk of the work by the end of the week
    • PRs for review
    • Spec repository and website repo separation
      • Use separate repos like today
        • Not optimised for web nor github
        • Flat navigation structure
      • Using separate repos, optimize for web view
        • Keep spec repo and branches/tags
        • Optimise rendering
        • Support multiple repos for SDK
      • Using one repo
        • Simplify development process for contribution of docs
      • Keep the secification only on GitHub
        • Keep dev process for spec simple
        • Optimise for GitHub view
      • Proof of concept
        • Dedicated branch for experimentation
      • Proposed next steps
        • Keep two repos
          • cdevents.dev, docsy repo
          • spec, purely browsed through GitHub
        • Remove submodule in cdevents.dev
        • Move primer, roadmap and non reference docs to cdevents.dev
        • We can still use the dropdown with version of the spec
          • Links point to GitHub
          • Needs some experimentation
          • Maybe use an iframe on the website to show GitHub content
        • In future we can evaluate more professional rendering of the spec

  • Connecting events

    • Event Links
      • Eiffel model
      • Database of events
      • Links with different semantics
    • Propagated Context
      • Issue to be created by Ben
      • If an event does not have a context, it generates one (UUID)
      • Events pass along a list(?) of contexts from "source" events
      • Context ID meant to be used to easily filter events
        • For the CloudEvents binding it could be a CE extension
    • Existing art

  • SDK Updates:

    • Java SDK
    • Python SDK
    • Golang SDK
    • GitHub Action

  • 0.2 planning

Nov 23rd

Participants:

  • Andrea Frittoli, he/him, IBM, UTC
  • Brad McCoy, he/him, Basiq, UTC
  • Terry Cox, he/him, Bootstrap Ltd, UTC
  • Hergy Tchuinkou, he/him, Prodyna SE, UTC

Agenda:

  • Specification updates

  • CDEvents and Jenkins X

  • CDEvents website & docs updates

    • Replay spec changes to spec-v0.1 branch
    • Andrea to update the spec-v0.1 branch
    • Diagrams
      • It would be nice to have more diagrams in the spec
      • Mermaid works for GitHub
      • Draw.io sources + SVG in the repo is what we've done in a few places
      • We should document the best practice for diagrams in CONTRIBUTING.md
      • Majority of diagrams will be in the primer.md

  • Incident events

    • Incident subjects
      • Fields: ID, source, Environment, Service, Kind
        • Source can be monitoring system, the application itself, a ticketing system, an SRE
        • ID is a UUID
        • Environment and Service are a references
        • Kind could be something that describes the kind of degradation that was detected, with a fixed set of keywords
          • Response time, reliability, functional
        • SLA breached
        • Best practices SIG / Supply Chain SIG - Maturity Workflow
          • Working on describing metrics associated with key activices
        • Priority
      • Predicate:
        • Update / Report
        • Finish / Restore
        • No start event?
        • Remediation
        • Ignored / accepted
          • Technical debt / accepted risk
          • Capturing this is important for metrics / audit trail
        • Upgrade / downgrade / triaged
      • Incident report can be a risk or an issue
      • The time the incident is reported is not necessarily the time the incident is started
    • Remediation subject?
      • Important to capture decisions not to act based on an incident
      • Keep track of what was done before to address an incident / issue
    • Metric?
      • We could use events to report changes in a metric
        • A change beyond a certain threshold would be an incident
      • Maybe OpenTelemetry is best used for that
        • OpenTelemetry reports values of metrics
        • Event could be used to react to a change

  • Connecting events

    • Event Links
      • Eiffel model
      • Database of events
      • Links with different semantics
    • Propagated Context
      • Issue to be created by Ben
      • If an event does not have a context, it generates one (UUID)
      • Events pass along a list? of contexts from "source" events
      • Context ID meant to be used to easily filter events
        • For the CloudEvents binding it could be a CE extension
    • Existing art

  • SDK Updates:

    • Java SDK
    • Python SDK
    • Golang SDK
    • GitHub Action

  • 0.2 planning

Nov 15th

Participants:

  • Ben Powell, Apple
  • Emil Bäckmark, UTC+1, Ericsson
  • Andrea Frittoli, he/him, IBM, UTC
  • Erik Sternerson, doWhile
  • Jalander Ramagiri, Ericsson Software Technology
  • Terry Cox, Bootstrap Ltd
  • Dadisi Sanyika, Apple
  • Rajat Gupta, Jenkins X

Agenda:

  • Related to Links are the need for a context id

    • A context ID could help tracing through event in an e2e flow
    • Use cases and suggestions
    • Overarching system / graph front-end would benefit from links to present relationships between events
    • Querying links vs. querying by context
    • A context ID requires a starting event
      • How is the starting event defined?
    • We could include an optional context ID, that a system could inject
      • Define rules about how the context ID is propagated
      • Define how a system is know it's the starting point for the context ID to be generated
    • This could be a case of an annotated envelope
    • Context ids / span ids are already widely used in observability so we should reuse the benefits seen there
    • Ben will write an issue on span ids

  • Spec versioning

    • Current status:
      • spec version is a field in all events
      • schema defines version as enum with default value
      • schema id includes the spec version e.g. https://cdevents.dev/0.1.1/schema/artifact-packaged-event
    • Create a new release means that:
      • The enum for version must be updated in all schemas.
        • Since this changes the schema, it actually requires a new version of the event type as well
      • The id must be updated in all schemas
    • Possible solutions:
      1. remove the enum for version, add the enum for type, update the SDK to validate the value for version
      2. remove version completely from the context and from the id, use the event type version in the schema id
      3. other ideas?

  • Java SDK

    • Java SDK is based on the old draft spec, the event format is different, there is no customData
    • Spinnaker (Java based) is interested in integrating CDEvents
    • Fidelity is interested in integrating CDEvents through the Java SDK, and they would need customData
    • Can we prioritize work on the Java SDK? Who's available to work on it?
    • Plan for v0.1 release
    • The CDEvents PoC will also be updated to use the updated Java SDK and Go SDK versions
    • cdevents/sdk-java#11

  • Python SDK

    • Current status?
    • Plan for v0.1 release
    • CLI? Which, if any, SDK should have it?
      • We'll probably prioritize the Go SDK as the CLI backend for now, since it is usually more uptodate, but we could also have other backends later.

  • GitHub action updates

    • ?

  • 0.2 planning

    • It would be good to get assignees to various items in the roadmap to get an idea about

      • who's working on what

      • what kind of progress we may expect for 0.2

      • when should 0.2 happen

      • (Andrea) My current plan for 0.2 spec contributions (roughly in order)

  • Upcoming events

    • KubeCon EU CFP closes on Nov 18th

  • Website refresh ongoing by Terry

Nov 8th

Participants:

  • Emil Bäckmark, Ericsson
  • Mattias Linnér, Ericsson
  • Terry Cox, Bootstrap
  • Jalander Ramagiri, Ericsson Software Technology
  • Brad McCoy, Basiq

Agenda:

Nov 1st

Participants:

  • Ben Powell, Apple
  • Erik Sternerson, doWhile
  • Emil Bäckmark, Ericsson
  • (Vibhav)
  • (Terry)
  • (Tracy)

Agenda:

  • Meeting starts at 4pm UTC

  • Demo: CDEvents Action for Github (Vibhav Bobade)

    • Background and discussion kept in this Google doc: https://docs.google.com/document/d/1_99RkPZXqEXynthAB0sZfxe-ETTLCuCcQySUQdufAtw/edit
    • We discussed a mapping for the different GitHub Actions to CDEvent types, which is now captured in the Google doc
      • Proposed to use customData for any missing event types to begin with, instead of waiting for new event types to get into the spec, to not delay to PoC itself
    • Use CDEvents to signal that e.g. GitHub is non-responsive or overloaded? There are use cases for this (Terry), but whether it should be solved using CDEvents only or using a combination of CDEvents and e.g. OpenTelemetry data is to be evaluated further.
    • What SDK to use for this GitHub Actions PoC? Any. The Go SDK is available now. The Python SDK is soon there (see below). A Java SDK is on its way. Using/forking the cloudevents-generator is also a valid option.

  • SDK status updates

    • Python SDK:
      • PR#11 for sending schema-compliant events.
      • Not a good user experience currently.
      • No support for parsing events yet.

  • Didn't reach to this topic today: Plan for CDEvents release v0.2, considering our roadmap and the roadmap project

Oct 26th

Canceled due to KubeCon NA

Oct 18th

Participants:

  • Andrea Frittoli, he/him, IBM, UTC+1
  • Emil Bäckmark, he/him, Ericsson, UTC+2
  • Erik Sternerson, he/him, doWhile, UTC+2

Agenda:

  • Adopting CDEvents PR: cdevents/spec#77

  • Release v0.1 review https://github.com/orgs/cdevents/projects/1/views/1

  • SDK status updates

    • Go SDK
      • Versioning (WIP)
      • Missing fields (WIP)
      • Version switch (TBD)
      • Tag/release
    • Python SDK
      • Spec data types (done)
      • Producing schema-valid JSON (needs verification)
      • Parsing schema-valid JSON (not started)
      • Versioning (not started)
      • CloudEvents mapping (not started)
      • CloudEvents binding/transport (not started)
      • Readme (not started)
      • Can be completed end-of-week at the earliest.

  • cdevents.dev

Oct 4th

Participants:

  • Andrea Frittoli, he/him, IBM, UTC+1
  • Erik Sternerson, doWhile
  • Emil Bäckmark, Ericsson, UTC+2
  • Ben Powell, Apple

Agenda:

  • Review v0.1.0 project

    • https://github.com/orgs/cdevents/projects/1/views/1
    • Release planning:
      • Decision deadline Oct 17th, best asap
      • Technical work cut off date 17/10
      • Release preparation (admin, release process): 17/10 -> 21/10
        • Spec:
          • Update from draft to v0.1.0
          • Make a release with git tag and release notes
        • SDKs:
          • Update from draft to v0.1.0
          • Make a release with git tag and release notes
        • Blog post / Article
          • We should start ASAP
          • Check with Fatih what kind of content
          • Whitepaper review
        • Last week before KubeCon will be busy
        • Presentation to the TOC
      • Summit on 25/10
    • Post release activies
      • Share on social media
      • Interviews?
      • Proof of concepts updated for v0.1
      • Presentation to TOC
      • Presentation to other communities
        • Tekton
        • Keptn
        • Spinnaker
        • Jenkins
    • Decision: we will make v0.1.0 before the cd summit!

  • New fields planned for the spec (already in Andrea's fork of the SDK):

  • v0.2.0 Roadmap ideas

    • Align naming with interop SIG dictionary
    • Introduce incident events
    • SSSC aspects: artifact SBOM, signature, artifact verified event
    • Test types coded in CDEvents
    • Golang, Python, Java SDK updated
    • SDK conformance tests from spec
    • Compositions, input/output artifact model
      • PoC dependency updates through events
    • Integration with tools
    • CDEventer / reusable CDEvent receiver/adapter
    • Inter-event references/links

  • Hacktoberfest contributions

Sept 28th

Participants:

  • Brad McCoy
  • Andrea Frittoli

Agenda:

Sep 20th

Participants:

  • Emil Bäckmark, Ericsson
  • Ben Powell, Apple
  • Erik Sternerson, doWhile
  • Kara de la Marck, CDF

Agenda:

  • Revisited the discussion about headers vs payload for the CDEvents specific data
    • CDEvents don't intend to replace existing messages sent in existing tools, but rather to complement it by providing a new way to send information to be the base for interoperability in CI/CD systems.
    • Action: Ben - write an issue for this on GitHub https://github.com/cdevents/spec/issues
  • Action items from last time

SDK / Spec changes from the OSS Demo

Sep 14th

Meeting canceled due Open Source Summit

Sep 6th

Participants:

  • Andrea Frittoli, he/him, IBM, UTC+1
  • Emil Bäckmark, Ericsson, UTC+2
  • Kara de la Marck, CDF, UTC-4
  • Jalander Ramagiri, Ericsson Software Technology, UTC+1
  • Erik Sternerson, doWhile

Agenda:

  • Action items from last time:

    • spec: adding json schema: WIP cdevents/spec#61
    • spec: adding data field: cdevents/spec#63 -> merged
    • spec: Subscriber model considerations, add diagram to spec: TBD
    • document decision (from CDEvents community summit) about prescriptive events in the spec: TBD
    • poc / demo implementation: Create issue to track this work: TBD

  • Versioning: cdevents/spec#43

    • From SDK user pov, users are most likely interested to send an event by spec version (event version is then implied)
    • The receiving side needs to know the event version (spec version is not so relevant)
    • Proposed starting approach
      • Version in the context for the spec, free text
      • Semantic version for events in the event type string

  • CDEventer demo (Andrea)

  • Documentation format:

  • Go SDK unit tests: cdevents/sdk-go#2 -> Issue clused now

  • Document general required features for sdk

    • Community repo
    • Unit test coverage
    • Conformance tests (hosted in the spec/jsonschema?)
    • We need to pin the spec version in the SDK

Aug 31st

Participants:

  • Andrea Frittoli, he/him, IBM, UTC+1
  • Emil Bäckmark, Ericsson, UTC+2
  • Mattias Linnér, Ericsson, UTC+2
  • Brad McCoy, he/him, Basiq, UTC+11

Agenda:

  • Action items from last time:

    • sdk-go: support for validating through json schema: DONE
    • spec: adding json schema: WIP cdevents/spec#61
    • spec: adding data field: TBD cdevents/spec#60
    • spec: add the version to the schema: DONE in the go-sdk, for the spec: cdevents/spec#61
    • java-sdk: Check with Jalander if he plans to update the Java SDK with the new spec version (draft/v0.1): TBD
      • Java SDK presentation at OSS Mini summit with Eiffel
      • No plan on updating the SDK before v0.1
      • It should not be a requirement for v0.1, but it still could be done
      • We should work on it at least once v0.1 is released
    • spec: Subscriber model considerations, add diagram to spec: TBD
    • document decision (from CDEvents community summit) about prescriptive events in the spec: TBD
    • poc / demo implementation: Create issue to track this work: TBD

  • sdk-go: discuss comments on cdevents/spec#61

  • spec/sdk: event versions

    • Old and new SDK include v1 in event types:
      • dev.cdevents.artifact.packaged.v1
    • Spec does not include version in event types:
      • dev.cdevents.artifact.packaged
    • (Andrea) I think we should include version
    • What versioning schema do we use and how does it compare to the spec version? cdevents/spec#43

  • poc / demo implementation

    • Mattias: Could the SDK serve this purpose?
    • Emil: SDK (one or more will be used), but do not rely on specific tools (Tekton, Jenkins, etc)
    • Mattias: we should lower the barrier for getting started with CDEvents
    • Emil: existing POCs can be complex to understand as they require specific tool knowledge
    • A simple CDEvent listener / display tool would be useful
    • We could use the TOC budget for CDEvents for that project
    • (A) Bring the topic to the next TOC meeting
    • (A) Find the issue with the description of the project

  • spec format:

  • (Brad) Using k8s events to generate CloudEvents / CDEvents

Aug 23rd

Participants:

  • Andrea Frittoli, he/him, IBM, UTC+1
  • Erik Sternerson, doWhile
  • Tarek Badr, doWhile
  • Ben Powell, Apple
  • Emil Bäckmark, Ericsson

Agenda:

Aug 17th

Participants:

  • Mattias Linnér, Ericsson
  • Emil Bäckmark, Ericsson
  • Andrea Frittoli
  • Brad McCoy

Agenda:

Aug 9th

Participants:

  • Erik Sternerson, doWhile
  • Tarek Badr, doWhile :)
  • Andrea Frittoli, IBM
  • Emil Bäckmark, Ericsson
  • Ben Powell, Apple
  • Kara de la Marck, CDF

Agenda:

  • Meeting recordings

    • Updated to youtube via Zapier (Andrea's personal account)
    • One manual step left, add video to playlist, set to public

  • Python SDK demo

    • (Erik&Tarek) Think about minimum supported Python version
      • Cloudevents Python SDK is Python 3.6+

  • Should we align across SDKs?

    • In terms of SDK, we shall follow standard expectation for each specific language
    • We need cross-compatibility / conformance tests across SDKs

  • SDK "readiness" checklist

    • Send events?
    • Receive events?
    • "Classes" for all event types?
      • Classes can have strongly typed properties and documentation, which gives a better user experience in many cases.
    • Other?
      • Documentation
        • Generated docs
        • Basic README intro to the project
      • Test cases / conformance tests (cross-sdk)

  • Shall we have one CLI?

    • We need to pick a language
      • Python: pros, no arch specific builds, cons: you need the correct python version
      • Go: multiplatform, but it requires multiple builds
      • (Andrea) create an issue to track this discussion

  • Go SDK

    • Andrea started working on the SDK
    • Proposed API for the SDK:
      • Create generic CDEvent by source, subjectId
        • Version is set automatically, can be overwritten
        • Event ID is generated (?), can be overwritten
        • Timestamp is set to the even creation time, can be overwritten
        • Subject source and event source are set to source
      • SubjectContent lets read/write fields by key name
      • One go struct per event type, which meets the SubjectContent interface
      • Create the struct, set it to the event 
        • cdevent := NewEvent(subjectId, source)
sc := PipelineRunQueuedSubjectContent{
      PipelineName: "pipeline",
      URL: "someurl",
}
cdevent.SetContent(sc)
        • Sets the event type in the main event
        • Sets the subject content
      • Get the event as CloudEvent, send it through the CloudEvents SDK go client 
        • ce := cdevent.AsCloudEvent()
result := ceClient.Send(cloudevents.ContextWithRetriesExponentialBackoff(ctx, 10*time.Millisecond, 10), *ce);
    • Using generic in go?
    • We need to be able to receive cdevents into defined objects
    • Working with empty interfaces can be painful

  • For the CLI probably keep the same structure as today?

  • Binary vs Structured mode

    • Andrea to roll back existing part about binary/structured
    • Add new field for vendor data

Aug 3rd

Meeting canceled

July 26th

Participants:

  • Andrea Frittoli, IBM
  • Erik Sternerson, doWhile

Agenda:

  • Metrics POC events

    • Change events
      • Merged event
        • Data model missing
          • Sha of last commit
          • List of all shas
    • Artifact events
      • Source repos and last sha for each
        • Using a list from the start
        • Let's try with a list
        • we can revert to a single repo if running into issues during the POC
      • Assumption
        • Many cases with a single repo
        • Some cases with many repo
        • Let's try use the latter to cover all cases
      • PR soon
    • Incident events
      • Add new stage?
      • Incident created, updated, resolved
      • PR with bare minium data model

  • Binary Mode POC

    • cdevents/spec#54
    • What about deeper levels
      • Other not support them in "binary" mode
      • Json serialised to string
      • Base64 encoded (to be signalled to receivers)
    • Why "binary" mode?
      • We could have clearer naming like HTTP header mode
      • Andrea to check with CloudEvents team
      • Consistency of naming may be a plus

  • Python SDK

    • Work progressing

  • Meetings

    • Weekly cadence
      • Alternating weeks help us progress
    • How do we make sure people who can attend one meeting (and not both) do not feel left out
      • Recap in the beginning of the meeting?
      • Advice to read the notes
      • Upload for meetings
        • Andrea to look into recording automation

  • Java SDK: https://github.com/cdevents/sdk-java

July 20th

Participants:

  • Erik Sternerson, doWhile
  • Andrea Frittoli, IBM
  • Mattias Linnér, Ericsson
  • Meha Bhalodiya
  • Vibhav Bobade, Uffizzi
  • Jamie Plower, Fidelity Investments

Agenda:

  • Updates

  • Build events

    • cdevents/spec#37
    • What do we mean by change?
      • PR/MR/etc or
      • Commit sha
    • Eiffel does not have a build event
    • Eiffel has a concept of composition
      • A composition may combine multiple inputs, with a version
    • Jamie - SCM event correlates to clone event which correlates to artifact
    • We could use artifacts only for the metrics POC

  • CDEvents content mode (on top of CloudEvents HTTP Binary mode):

    • Structured:
      • JSON payload with CDEvents meta, subject, links as "payload"
      • Content type for payload content?
      • Content-Type: application/cdevents+json; charset=utf-8
ce-headers: ...

{
 "meta": {
    "version": "draft",
    "id": "A234-1234-1234",
    "source": "/staging/tekton/",
    "type": "dev.cdevents.taskrun.started",
    "timestamp": "2018-04-05T17:31:00Z",
    "datatype": "application/json+my-vendor-app"
 }
 "subject": {
    "id": "/namespace/taskrun-123",
    "type": "taskrun",
    "content": {
       "task": "my-task",
       "URL": "/apis/tekton.dev/v1beta1/namespaces/default/taskruns/my-taskrun-123"
       "pipelinerun": {
          "id": "/somewherelse/pipelinerun-123",
          "source": "/staging/jenkins/"
       }
    }
 }
 "data": { <vendor-data> }
 }
    • Binary:
      • CDEvents meta, subject, links all in HTTP headers
      • Content-Type: application/xml; charset=utf-8
ce-headers: ... 
cde-meta:  version=draft; id=A234-1234-1234; source=/staging/tekton/; type=dev.cdevents.taskrun.started; timestamp=2018-04-05T17:31:00Z
  cde-subject: id=/namespace/taskrun-123; type=taskrun; content-task=my-task; content-URL=/apis/tekton.dev/v1beta1/namespaces/default/taskruns/my-taskrun-123; content-pipelinerun-id=/somewherelse/pipelinerun-123; content-pipelinerun-source=/staging/jenkins/

<xml>
    <root>Some vendor content</root>
</xml>

  • Community repo (Andrea)

    • Plan to create a cdevents/community repo over the summer
    • Migrate existing relevant docs and links
    • Define governace docs in the new repo

  • CDEvents visualisation

  • Spec feature branches for POCs?

July 12th

<No meeting>

July 6th

Participants:

  • Emil Bäckmark, Ericsson, UTC+2
  • Andrea Frittoli, IBM, UTC+1
  • Mattias Linnér, Ericsson, UTC+2
  • Meha Bhalodiya
  • Brad McCoy, UTC+10

Agenda:

  • Brad to go over Flux integration for CDEvents
  • Introduce Subjects: cdevents/spec#35
    • Type:
      • The first part is all reverse DNS
      • We can keep all lower case?
    • UpperCamelCase vs lowerCamelCase
      • lowerCamelCase seems more popular
      • we should use same format for keys and enum values
      • document the decision as part of the PR
    • Subjects and Predicates cdevents/spec#35 (comment)
      • When grouping events, having the static part of the subject separate could be useful
      • Split this into a different PR?
  • CDEvents content mode (on top of CloudEvents HTTP Binary mode):
    • Structured:
      • JSON payload with CDEvents meta, subject, links as "payload"
      • Content type for payload content?
      • Content-Type: application/cdevents+json; charset=utf-8
ce-headers: ...

{
 "meta": {
    "version": "draft",
    "id": "A234-1234-1234",
    "source": "/staging/tekton/",
    "type": "dev.cdevents.taskrun.started",
    "timestamp": "2018-04-05T17:31:00Z",
    "datatype": "application/json+my-vendor-app"
 }
 "subject": {
    "id": "/namespace/taskrun-123",
    "type": "taskrun",
    "content": {
       "task": "my-task",
       "URL": "/apis/tekton.dev/v1beta1/namespaces/default/taskruns/my-taskrun-123"
       "pipelinerun": {
          "id": "/somewherelse/pipelinerun-123",
          "source": "/staging/jenkins/"
       }
    }
 }
 "data": { <vendor-data> }
 }
      • Useful for storing events as JSON blobs in a DB
        • Do we need the CloudEvents part there too?
          • We could consider structured mode on top of CloudEvents structured, mostly for this kind of storage as JSON use cases
    • Binary:
      • CDEvents meta, subject, links all in HTTP headers 
        Content-Type: application/xml; charset=utf-8
ce-headers: ... 
cde-meta:  version=draft; id=A234-1234-1234; source=/staging/tekton/; type=dev.cdevents.taskrun.started; timestamp=2018-04-05T17:31:00Z
cde-subject: id=/namespace/taskrun-123; type=taskrun; content-task=my-task; content-URL=/apis/tekton.dev/v1beta1/namespaces/default/taskruns/my-taskrun-123; content-pipelinerun-id=/somewherelse/pipelinerun-123; content-pipelinerun-source=/staging/jenkins/
  
<xml>
    <root>Some vendor content</root>
</xml>

June 28th

Participants:

  • <add yourself>
  • Andrea Frittoli, he/him, IBM, UTC+1
  • Emil Bäckmark, he/him, Ericsson, UTC+2

Agenda:

  • Meetings

    • Poll: https://forms.gle/oC2qto7hjxBAGPvq8
    • Responses: https://docs.google.com/forms/d/1h2kmkcoV5CdeiFfFaLfGJ_dxuAIHb7I8D3hNy5R7bp0/edit#responses
    • Existing meeting time
    • (Andrea) Make proposals in CDEvents channel for specific times/dates and ask people to vote
      • Avoid conflicts within the CDF calendar
      • Options (added after the meeting)
        • 1️⃣ Monday July 4th, 10am UTC, and then every other week
        • 2️⃣ Monday July 4th, 11am UTC, and then every other week
        • 3️⃣ Tuesday July 5th, 10am UTC, and then every other week
        • 4️⃣ Tuesday July 5th, 11am UTC, and then every other week
        • 5️⃣ Wednesday July 6th, 10am UTC, and then every other week
        • 6️⃣ Wednesday July 6th, 11am UTC, and then every other week
    • We would have three meetings in total
      • SIG meeting
      • 2 CDEvent meetings
    • Who would be interested in joining from Pacific
      • Ben
      • Check who else
      • We could have a shorter follow-up meeting at a Pacific friendly time?

  • Updates on cdevents/spec#35

    • Updated data section, introduced content modes in cloudevent-binding.md

    • Changed format of fields on core.md

    • Addressed comments on spec.md

    • Schema updates pending - move schemas to different PR?

    • To be done - next PR?

      • CDEvents binary mode (all in headers, vendor data in payload)
      • Full examples for various modes, including vendor payload

    • Up next: Updates to the rest of vocabulary docs, similar to core.md

  • Aligning the vocabulary with SIG Interop

    • cdevents/spec#18
      • Interop WG: Pipeline, stage, step
      • CDEvents: Pipelinerun, taskrun
    • Make a statement in our docs
      • We strive to align with SIG interop names from the vocabulary
      • The final naming won't be ready in time for v0.1
      • People should be aware that names may/will change in later releases
    • (Andrea) Reach out / join Interop SIG to clarify plan for defining the names
    • Comment on issue cdevents/spec#18
      • Create a new issue for the docs part discussed today

  • Roadmap:

  • Support for links:

    • Anyone would like to propose spec changes?
    • Emil is interested

  • How to collaborate on spec

    • It's hard to collaborate on PR/issues for spec
    • We could attempt working on an hackmd docs until it's ready and then PR

  • SDKs

    • Python SDK updates
    • Java SDK targeted for v0.1

  • PR to review:

  • Create a community repo

    • Governance setup
    • PoC discussion
    • Overall cdevents issues / discussions (not spec specific)
    • Is it possible to move issues across orgs or export/import?

  • Summer meetings

    • It looks like enough people might be working through the summer
      • Erik, Jalander, Andrea
      • July 4th holiday in the US
      • Emil away 4 weeks after the 4th
    • Let's keep meetings in July and August

June 14th

Participants:

  • <add yourself>
  • Erik Sternerson, doWhile
  • Andrea Frittoli, he/him, IBM, UTC+1
  • Emil Bäckmark, Ericsson
  • Ben Powell, he/him, Apple
  • Kara de la Marck, CDF

Agenda:

May 31st

Meeting canceled due to no participants joining

May 3rd

Participants:

  • Emil Bäckmark, Ericsson
  • Andrea Frittoli, IBM
  • Mattias Linnér, Ericsson
  • Erik Sternerson, doWhile
  • <add yourself>

Agenda:

  • Introduction of objects and subjects: cdevents/spec#35
    • Spent the whole meeting discussing this
    • (Emil) add results from discussion on the PR
  • "Requested" events: cdevents/spec#36
    • We didn't have time to discuss this.
  • About CDEventsCon
    • Someone needs to be responsible to handle the chat from virtual audience and bring it to the in-person speaker

April 19th

Participants:

  • Emil Bäckmark, Ericsson
  • Liora Milbaum, RedHat

Agenda:

  • cdevents/spec#36
    • We didn't bring this up due to lack of participants in the meeting.
  • Since it was only two people in the meeting we spent it on getting to know each others background and discussing the use/need of events in CI/CD and Software Supply Chains

April 5th

Participants:

  • Erik Sternerson, doWhile
  • Kevin Chu, GitLab
  • Emil Bäckmark, Ericsson
  • Tracy Ragan, DeployHub / Ortelius OS
  • Mattias Linnér, Ericsson

Agenda:

  • Events:
    • CDEvents at cdCon
      • Half a day, June 9th afternoon
        • Texas Time -> that's going to be night in Europe
        • Morning time will enable European participants to take part virtually
      • Title: CDEvents Community Summit
      • Event description:
        • CDEvents v0.1 is coming, let’s implement it in the wild! We are building SDKs for go, java and python - let’s use them to add CDEvents to your project. Meet at cdCon, CDEvents users and developers, to learn about CDEvents and start using them!
    • CDEventsCon
      • Registration is now live
      • Draft agenda available on dedicated sched page
      • Content to be finalised / confirmed:
        • Eiffel talk
        • Keptn workshop (Oleg driving this)
        • SIGs panel (Oleg helping to organise)
        • Spinnaker (lighting) talk
      • Setup for hybrid event being clarified
        • Which platform (zoom)?
        • Who's managing the virtual room?
          • Remote speakers
          • Access to stream for remote viewers
      • Kevin volunteered to help with the conference
      • Promoting the event:
  • SDKs
  • Spec

March 22nd

Participants:

  • Emil Bäckmark, Ericsson
  • Andrea Frittoli, IBM
  • Mattias Linnér, Ericsson
  • <add yourself>

Agenda:

Events:

Workshops:

  • Write an receive/send adapter with the SDK?

Proof of Concepts:

SDKs:

  • Defined schemas will help with SDK creations
    • Andrea is working on this
  • Golang
  • Python
  • Java

Pull Requests:

Interesting tool: https://github.com/direktiv/direktiv - Session for SIG Events

Andrea on PTO 07/04 -> 25/04

22nd February

Participants:

  • Andrea Frittoli
  • Mattias Linnér, Ericsson
  • Mauricio Salatino (salaboy), VMware
  • Ishan Khare
  • <add yourself>

Agenda:

8th February

Participants:

  • Erik Sternerson, doWhile
  • Kara de la Marck, CDF
  • Ishan Khare
  • Emil Bäckmark, Ericsson
  • Vibhav Bobade
  • <add yourself>

Agenda:

Meeting 25th January

Participants:

  • Andrea Frittoli, IBM, UTC
  • Mauricio Salatino, VMWare, UTC
  • Erik Sternerson, doWhile
  • Mattias Linnér, Ericsson
  • Ishan Khare

Agenda:

Meeting 11th January

Participants:

  • Mattias Linnér, Ericsson

  • Steve Taylor, DeployHub/Ortelius

  • Andrea Frittoli, IBM

  • Emil Bäckmark, Ericsson

  • FOSDEM Presentation

    • CI/CD Devroom - from developers, to developers
    • Key Takeways that people should get from the talk?
      • Interoperability
      • We want their INPUT
    • What does your CI/CD world look like?
      • What tools do you use together?
        • Perhaps a form with a pre-populated list of tools
      • Shall we get contact details / get in touch during the conference
      • Ideally we'd like a picture of a pipeline
        • Come give us a demo of your pipeline
      • Shortlink that we can re-point?
    • Key points
      • What do we do
      • What we need from you
      • How to contribute
    • Things to prepare
    • Two use cases
      • Interop between tools talking to each other
      • Interop between tools by collecting data consistently across tools (metrics)

  • CdCon 2022 CFP - https://cd.foundation/event/cdcon-2022/

  • Logo:

    • cdfoundation/foundation#348
    • Ideas for stacked versions:
    • Emil will update the issue with some of these proposals. Maybe also propose a "draft"/"preliminary" version to the landscape so we get that in? And post on Slack to SIG Events on the proposal

Previous meeting notes can be found on GitHub