diff --git a/rfcs/0006-cdevents/CDEvents-Flux-RFC-Broker.png b/rfcs/0006-cdevents/CDEvents-Flux-RFC-Broker.png deleted file mode 100644 index 2d1ab50e..00000000 Binary files a/rfcs/0006-cdevents/CDEvents-Flux-RFC-Broker.png and /dev/null differ diff --git a/rfcs/0006-cdevents/README.md b/rfcs/0006-cdevents/README.md index de4bc43c..e7017768 100644 --- a/rfcs/0006-cdevents/README.md +++ b/rfcs/0006-cdevents/README.md @@ -1,10 +1,6 @@ # RFC-0006 Flux CDEvents Receiver - - -**Status:** provisional +**Status:** implementable +This RFC proposes to add a `Receiver` type to the Flux notification-controller API +for handling [CDEvents](https://cdevents.dev/). + +For `Receiver` objects configured to accept CDEvents, +notification-controller will verify the events sent to the receiver's webhook URL, +check that their type matches the expected type, and trigger the reconciliation +of the configured resources. ## Motivation -CDEvents enables interoperability between supported tools in a workflow, and flux is a very popular continuous delivery tool, and consequently we have received many questions about implementing CDEvents into the tool. - +CDEvents enables interoperability between CI/CD tools in a workflow, and Flux is a +very popular continuous delivery tool, and consequently the CDF team received many questions +about integrating CDEvents with Flux. ### Goals -Integrate CDEvents into Flux with a CDEvents Receiver. - +Allow Flux to receive CDEvents and trigger the reconciliation of resources based on the received events. ### Non-Goals -A CDEvent provider will be handled as a separate RFC in the future. - - +Make the Flux controllers emit CDEvents. ## Proposal -Add CDEvents to the list of available receivers in Flux Notification controller. Similar to other receivers such as the github, the user will be able to use `spec.events` in order to specify which event types the receiver will allow. The receiver will also verify using the [CDEvents Go SDK](https://github.com/cdevents/sdk-go) that the payload sent to the webhook URL is a valid CDEvent. - - +Add CDEvents to the list of available receivers in Flux notification-controller. +Similar to other receivers such as GitHub, Flux users will be able to use `spec.events` +in order to specify which event types the receiver will allow. +The receiver will also verify using the [CDEvents Go SDK](https://github.com/cdevents/sdk-go) that the +payload sent to the webhook URL is a valid CDEvent. ### User Stories - +Users of multiple CI/CD tools such as Tekton and Flux +could use CDEvents as a way to enable interoperability. -Users of multiple different CI/CD tools such as Tekton and Flux could use CDEvents as a potential way to enable interoperability. For example, a user may want a Flux resource to reconcile as part of a Tekton `pipeline`. -The Tekton `pipeline` will fire off a CDEvent to the CloudEvents Broker. A subscription that the user will have set up externally, e.g. with the [knative broker](https://knative.dev/docs/eventing/brokers/) will then send a relevant CDEvent to the CDEvent Receiver within Flux. +For example, a user may want a Flux resource to reconcile as part of a Tekton `pipeline`. +The Tekton `pipeline` will fire off a CDEvent to the CloudEvents Broker. +A subscription that the user will have set up externally, e.g. with the [knative broker](https://knative.dev/docs/eventing/brokers/), will then +send a relevant CDEvent to the Flux webhook receiver endpoint. ![usecase](cdevents-flux-tekton.png) ### Alternatives -Certain use cases for CDEvents could be done alternatively using available receivers such as the generic webhook. +Certain use cases for CDEvents could be done alternatively using +available receivers such as the generic webhook. - +Adding a Flux `Receiver` for CDEvents that works much like the other event-based receivers already implemented. -## Design Details +The user will be able to define a Flux `Receiver` custom resource and deploy it to their cluster. +The receiver takes the payload sent to the webhook URL by an external events broker, +checks the headers for the event type, and filters out events based on the user-defined +list of events in `spec.events`. If left empty, it will act on all valid CDEvents. +It then validates the payload body using the [CDEvents Go SDK](https://github.com/cdevents/sdk-go). +Valid events will then trigger the reconciliation of all Flux objects specified in `.spec.resources`. -Adding a receiver for CDEvents that works much like the other event-based receivers already implemented. The user will be able to write a yaml file for the receiver and deploy it to their cluster. The receiver takes the payload sent to the webhook URL by an external events broker, checks the headers for the event type, and filters out events based on the user-defined list of events in spec.Events. If left empty, it will act on all valid CDEvents. It then validates the payload body using the [CDEvents Go SDK](https://github.com/cdevents/sdk-go). Valid events will then trigger reconciliation of the resources. The events broker is not a part of this design and is left to the user to set up however they wish. +The CDEvents broker is not a part of this design and is left to the users to set up however they wish. -Example Receiver YAML: +Example Receiver: ```yaml apiVersion: notification.toolkit.fluxcd.io/v1 @@ -102,26 +88,14 @@ spec: secretRef: name: receiver-token resources: - - kind: GitRespository - apiVersion: source.toolkit.fluxcd.io/v1 + - apiVersion: source.toolkit.fluxcd.io/v1 + kind: GitRepository name: webapp namespace: flux-system ``` ![User Flowchart](Flux-CDEvents-RFC.png) - - ![Adapter](CDEvents-Flux-RFC-Adapter.png)