From fb65def7aaf8f8b61da6f596027ed6e0643c7304 Mon Sep 17 00:00:00 2001 From: Carina Kothe <69976260+grischperl@users.noreply.github.com> Date: Thu, 9 Nov 2023 17:35:04 +0100 Subject: [PATCH] Eventing Manager Module Documentation (#226) * Add the docs for contributor * User documentation * Add automatically generated CRD documentation * Small improvements * Replace link * Apply review comments * Add review comments * Fix typo * Add review comments --- Makefile | 13 +++ docs/assets/reconcileLoop.svg | 4 + docs/contributor/development.md | 22 ++++ docs/contributor/governance.md | 45 ++++++++ docs/contributor/installation.md | 164 ++++++++++++++++++++++++++++ docs/contributor/testing.md | 73 +++++++++++++ docs/contributor/troubleshooting.md | 29 +++++ docs/user/01-manager.md | 36 ++++++ docs/user/02-configuration.md | 73 +++++++++++++ docs/user/README.md | 13 ++- 10 files changed, 470 insertions(+), 2 deletions(-) create mode 100644 docs/assets/reconcileLoop.svg create mode 100644 docs/contributor/development.md create mode 100644 docs/contributor/governance.md create mode 100644 docs/contributor/installation.md create mode 100644 docs/contributor/testing.md create mode 100644 docs/contributor/troubleshooting.md create mode 100644 docs/user/01-manager.md create mode 100644 docs/user/02-configuration.md diff --git a/Makefile b/Makefile index 5fe548b0..a5836056 100644 --- a/Makefile +++ b/Makefile @@ -89,6 +89,7 @@ help: ## Display this help. .PHONY: manifests manifests: controller-gen ## Generate WebhookConfiguration, ClusterRole and CustomResourceDefinition objects. $(CONTROLLER_GEN) rbac:roleName=eventing-manager crd webhook paths="./..." output:crd:artifacts:config=config/crd/bases + $(MAKE) crd-docs-gen .PHONY: generate generate: go-gen controller-gen ## Generate code containing DeepCopy, DeepCopyInto, and DeepCopyObject method implementations. @@ -314,3 +315,15 @@ e2e-eventing-peerauthentications: # e2e will run the whole suite of end-to-end tests for eventing-manager. .PHONY: e2e e2e: e2e-setup e2e-eventing-setup e2e-eventing e2e-cleanup + +TABLE_GEN ?= $(LOCALBIN)/table-gen +TABLE_GEN_VERSION ?= v0.0.0-20230523174756-3dae9f177ffd + +.PHONY: tablegen +tablegen: $(TABLE_GEN) ## Download table-gen locally if necessary. +$(TABLE_GEN): $(LOCALBIN) + test -s $(TABLE_GEN) || GOBIN=$(LOCALBIN) go install github.com/kyma-project/kyma/hack/table-gen@$(TABLE_GEN_VERSION) + +.PHONY: crd-docs-gen +crd-docs-gen: tablegen ## Generates CRD spec into docs folder + ${TABLE_GEN} --crd-filename ./config/crd/bases/operator.kyma-project.io_eventings.yaml --md-filename ./docs/user/02-configuration.md diff --git a/docs/assets/reconcileLoop.svg b/docs/assets/reconcileLoop.svg new file mode 100644 index 00000000..1605fbbf --- /dev/null +++ b/docs/assets/reconcileLoop.svg @@ -0,0 +1,4 @@ + + + +
Eventing CR
Eventing CR
Eventing Reconciler
Eventing Reconciler
NATS Path
NATS Path
EventMesh Path
EventMesh Path
Reconciliation Loop
Reconciliation LoopText is not SVG - cannot display \ No newline at end of file diff --git a/docs/contributor/development.md b/docs/contributor/development.md new file mode 100644 index 00000000..c3db1814 --- /dev/null +++ b/docs/contributor/development.md @@ -0,0 +1,22 @@ +# Setup + +Eventing Manager follows the [Kubernetes operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) and is scaffolded using [Kubebuilder](https://book.kubebuilder.io/). + +Projects created by Kubebuilder contain a Makefile with tooling that must be locally executed before pushing (for example, `git push`) to the repository. Refer to [Governance](./governance.md) for further details. + +## Prerequisites + +- [Go](https://go.dev/) +- [Docker](https://www.docker.com/) +- [kubectl](https://kubernetes.io/docs/tasks/tools/) +- [Kubebuilder](https://book.kubebuilder.io/) +- [kustomize](https://kustomize.io/) +- [golangci-lint](https://golangci-lint.run/) + +## Available commands +Commands are available for easier development and installation of Eventing Manager. +To find out which commands are available and for some more details about each command, run: + +```bash +make help +``` diff --git a/docs/contributor/governance.md b/docs/contributor/governance.md new file mode 100644 index 00000000..9d111c79 --- /dev/null +++ b/docs/contributor/governance.md @@ -0,0 +1,45 @@ +# Governance + +Some quality aspects are covered by automated verification, so you must execute tooling locally before a commit. +This document guides you through the development flow. + +## Modifying the API definitions + +This project uses the [controller-gen](https://book.kubebuilder.io/reference/controller-gen.html) tool provided by [Kubebuilder](https://book.kubebuilder.io/). +To modify the API definitions, you must adapt the ["marker comments"](https://book.kubebuilder.io/reference/markers.html) in the Go code. + +Additionally, this project uses [validation markers](https://book.kubebuilder.io/reference/markers/crd-validation.html) to provide CRD validation and defaulting with [OpenAPI v3 schemas](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.0.md#schemaObject). +The rules are written using the [Common Expression Language](https://github.com/google/cel-spec). +For further information and examples, look to the [Kubernetes documentation](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) of validation rules and the CEL [language definition](https://github.com/google/cel-spec/blob/v0.10.0/doc/langdef.md). + +After the modifications, run the following command to generate the new manifests, such as custom resources (CRs) and CustomResourceDefinitions (CRDs): +```sh +make manifests +``` + +If changes to the `runtime.Object` interface were made, the `DeepCopy` functions must be updated as well. +The generation is controlled by [Kubebuilder markers](https://book.kubebuilder.io/reference/markers/object.html?highlight=deep#objectdeepcopy). +```sh +make generate +``` + +## Source code linting + +The quality of this project is ensured by source code linting using [golangci-lint](https://golangci-lint.run/). + +To fix common lint issues, run the following command: + +```sh +make imports-local +make fmt +``` + +To run thorough lint checking, execute the following command: + +```sh +make lint-thoroughly +``` + +If necessary, lint warnings can be ignored. However, if this is desired you must provide a comment explaining the reason. Use the following format: + +`//no-lint: // ` diff --git a/docs/contributor/installation.md b/docs/contributor/installation.md new file mode 100644 index 00000000..a9bd95eb --- /dev/null +++ b/docs/contributor/installation.md @@ -0,0 +1,164 @@ +# Installation and uninstallation + +There are several ways to install Eventing Manager. +For development, you must run some make targets beforehand. +For information about the prerequisites, refer to [Development](./development.md) and for a detailed guide to the development flow, visit [Governance](./governance.md). + +## Run the manager on a (k3d) cluster using a Docker image + +### Installation + +1. Ensure you have a k3d cluster ready. + ```sh + k3d create cluster + ``` + + > **NOTE:** Alternatively to a k3d cluster, the Kubecontext can also point to any existing Kubernetes cluster. + +2. Install the CRD of Eventing Manager. + + ```sh + make install + ``` + +3. Export the target registry. + + If you are using Docker, `` is your username. + + ```sh + export IMG=/: + ``` + +4. Build and push your image to the registry. + + ```sh + make docker-build docker-push IMG=$IMG + ``` + + > **NOTE:** For MacBook M1 devices, run: + > + > ```sh + > make docker-buildx IMG=$IMG + > ``` + +5. Deploy the controller to the k3d cluster. + + ```sh + make deploy IMG=$IMG + ``` + +6. To start the reconciliation process, apply the Eventing custom resource (CR). +This step depends on your desired backend: NATS or EventMesh. + + - **Backend: NATS** + + For NATS Backend you can apply the default CR using the following command: + + ```sh + kubectl apply -f config/samples/default.yaml + ``` + + The `spec.backend.type` needs to be set to `NATS`. You can configure the backend using the `NATS` related field in `spec.backend.config`. + + ```sh + spec: + backend: + type: NATS + config: + natsStreamStorageType: File + natsStreamReplicas: 3 + natsStreamMaxSize: 700M + natsMaxMsgsPerTopic: 1000000 + ``` + + - **Backend: EventMesh** + + For EventMesh Backend you can apply the default CR using the following command: + + ```sh + kubectl apply -f config/samples/default_eventmesh.yaml + ``` + + - `spec.backend.type`: set to `EventMesh` + - `spec.backend.config.eventMeshSecret`: set it to the `/` where you applied the secret + - `spec.backend.config.eventTypePrefix`: change to your desired value or leave as is + - `spec.backend.config.domain`: set to the cluster public domain + + If the Kyma Kubernetes cluster is managed by Gardener, Eventing Manager reads the cluster public domain automatically from the ConfigMap `kube-system/shoot-info`. + Otherwise, you need to additionally set `spec.backend.config.domain` in the configuration. + + ```sh + spec: + backend: + type: "EventMesh" + config: + eventMeshSecret: "/" + eventTypePrefix: "" + domain: "" + ``` + +7. Check the `status` section to see if deployment was successful. + + ```shell + kubectl get -n -o yaml + ``` + + >**Note:** Usually, the default values are as follows: + > + > ```shell + > kubectl get eventings.operator.kyma-project.io -n kyma-system -o yaml + > ``` + +### Uninstallation + +1. Remove the controller. + + ```sh + make undeploy + ``` + +2. Remove the resources. + + ```sh + make uninstall + ``` + +## Run Eventing Manager on a cluster using the Go runtime environment + +### Installation + +1. Ensure you have the Kubecontext pointing to an existing Kubernetes cluster. + +2. Clone Eventing Manager project. + +3. Download Go packages. + + ```sh + go mod vendor && go mod tidy + ``` + +4. Install the CRD of Eventing Manager. + + ```sh + make install + ``` + +5. Run Eventing Manager locally. + + ```sh + make run + ``` + +### Uninstallation + +Remove the resources. + + ```sh + make uninstall + ``` + +## Run Eventing Manager using Kyma's Lifecycle Manager + +[Kyma's Lifecycle Manager](https://github.com/kyma-project/lifecycle-manager) helps manage the lifecycle of each module in the cluster and can be used to install Eventing Manager. + +To run Eventing Manager, follow the steps detailed in the [Lifecycle Manager documentation](https://github.com/kyma-project/lifecycle-manager/tree/main/docs). diff --git a/docs/contributor/testing.md b/docs/contributor/testing.md new file mode 100644 index 00000000..30a07abd --- /dev/null +++ b/docs/contributor/testing.md @@ -0,0 +1,73 @@ +# Testing + +This document provides an overview of the testing activities used in this project. + +## Testing Levels + +| Test suite | Testing level | Purpose | +|------------|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Unit | Unit | This test suite tests the units in isolation. It assesses the implementation correctness of the unit's business logic. | +| Env-tests | Integration | This test suite tests the behavior of Eventing Manager in integration with a Kubernetes API server replaced with a test double. It assesses the integration correctness of Eventing Manager. | +| E2E | Acceptance | This test suite tests the usability scenarios of Eventing Manager in a cluster. It assesses the functional correctness of Eventing Manager. | + +> **NOTE:** The validation and defaulting rules are tested within the integration tests. + +### Unit tests and env-tests + +To run the unit and integration tests, the following command must be executed. If necessary, the needed binaries for the integration tests are downloaded to `./bin`. +Further information about integration tests can be found in the [Kubebuilder book](https://book.kubebuilder.io/reference/envtest.html). + + ```sh + make test-only + ``` + +If changes to the source code were made, or if this is your first time to execute the tests, the following command ensures that all necessary tooling is executed before running the unit and integration tests: + + ```sh + make test + ``` + +### E2E tests + +Because E2E tests need a Kubernetes cluster to run on, they are separate from the remaining tests. + +1. Ensure you have the Kubecontext pointing to an existing Kubernetes cluster and Eventing Manager has been deployed. + + > Note: Creating Eventing custom resource (CR) is optional. If Eventing CR already exists, the test updates the CR to meet the requirements of the test. + +2. Export the following ENV variables. + + ```sh + export BACKEND_TYPE="NATS" # if using NATS Backend + export BACKEND_TYPE="EventMesh" # if using EventMesh Backend + ``` + +2. Execute the whole E2E test suite. + + ```sh + make e2e + ``` + +The E2E test consists of four consecutive steps. If desired, you can run them individually. For more information, read the [E2E documentation](https://github.com/kyma-project/eventing-manager/blob/main/hack/e2e/README.md). + + + +## CI/CD + +This project uses [Prow](https://docs.prow.k8s.io/docs/) and [GitHub Actions](https://docs.github.com/en/actions) as part of the development cycle. +The aim is to verify the functional correctness of Eventing Manager. + +### Prow Jobs + +The Prow Jobs that cover the code of this repository reside in [their own repository](https://github.com/kyma-project/test-infra/tree/main/prow/jobs/kyma-project/eventing-manager). +Presubmit Jobs run on pull requests (PRs) and are marked with the prefix `pull`. Postsubmit jobs run on branch `main` after a PR has been merged and carry the prefix `post`. + +For more information on execution details of each Job, refer to their `description` field and the `command` and `args` fields. +Alternatively, you can access this information from your PR by inspecting the details to the job and viewing the Prow job `.yaml` file. + +### GitHub Actions + +GitHub Actions reside [within this module repository](https://github.com/kyma-project/eventing-manager/tree/main/.github/workflows). +Pre- and postsubmit actions follow the same naming conventions as Prow Jobs. + +The [Actions overview](https://github.com/kyma-project/eventing-manager/actions/) shows all the existing workflows and their execution details. Here, you can also trigger a re-run of an action. diff --git a/docs/contributor/troubleshooting.md b/docs/contributor/troubleshooting.md new file mode 100644 index 00000000..3bc55344 --- /dev/null +++ b/docs/contributor/troubleshooting.md @@ -0,0 +1,29 @@ +# Troubleshooting + +This document contains tips and tricks for common problems with Eventing Manager and will be updated continuously. + +If you cannot find your issue described here, take a look at the [Eventing Troubleshooting](https://github.com/kyma-project/eventing-manager/blob/main/docs/user/troubleshooting/README.md) + +## Troubleshooting: Installing Eventing Manager using a Docker image + +### Error while deploying Eventing Manager + +**Symptom:** The `make deploy` step fails with the following error message: + +`Error from server (NotFound): error when creating "STDIN": namespaces kyma-system not found` + +**Cause:** The Namespace of the Deployment does not exist yet. + +**Remedy:** Create the Namespace. + + ```sh + kubectl create ns kyma-system + ``` + +## Reach out to us + +If you encounter an issue or want to report a bug, please create a [GitHub issue](https://github.com/kyma-project/nats-manager/issues) with background information and +steps on how to reproduce. + +If you want to contact the eventing team directly, you can reach us in Slack [Eventing channel](https://kyma-community.slack.com/archives/CD1C9GZMK) +or tag us `@kyma-eventing` in the Slack [Kyma Tech channel](https://sap-ti.slack.com/archives/C0140PCSJ5Q). diff --git a/docs/user/01-manager.md b/docs/user/01-manager.md new file mode 100644 index 00000000..6a6c3063 --- /dev/null +++ b/docs/user/01-manager.md @@ -0,0 +1,36 @@ +# Eventing manager + +This module ships Eventing Manager. Once this module is enabled, it provides the functionality to send and receive events. + +## Module lifecycle + +Upon starting Eventing Manager, the controller (following the [Kubebuilder concept](https://book.kubebuilder.io/architecture.html)) creates, watches, and reconciles the following resources: + +- ConfigMap +- Secret +- Service +- Stateful Set +- Destination Rule +- Pod Disruption Budget + +Eventing Manager reacts to changes in the Eventing custom resource (CR) to adapt the resources mentioned above to the desired state. For details on how to configure Eventing using the CR, visit the [Configuration documentation](02-configuration.md). + +![Eventing Manager reconciliation loop](../assets/reconcileLoop.svg) + +## Backend + +Eventing Manager supports switching between two different backends. [NATS](https://nats.io/about/), an open source messaging system, and [EventMesh](https://help.sap.com/docs/event-mesh/event-mesh/what-is-sap-event-mesh), a SAP solution for event-based architecture. + +- **NATS** + + If you want to use Eventing Manager with NATS backend, you must deploy the [NATS module](https://github.com/kyma-project/nats-manager). + +- **SAP EventMesh** + + If you want to use Eventing Manager with EventMesh backend, you must deploy the [API-Gateway module](https://github.com/kyma-project/api-gateway). + +For more information about the possible configuration of Eventing Manager using NATS or EventMesh backend, refer to the [backend configuration](02-configuration.md#reference). + +## Removing the module + +The module cannot be removed as long as Subscription CRs exist. After the user cleans up all the subscriptions, the Eventing module can be removed. The module takes care of cleaning up all resources owned by it. diff --git a/docs/user/02-configuration.md b/docs/user/02-configuration.md new file mode 100644 index 00000000..da4db46f --- /dev/null +++ b/docs/user/02-configuration.md @@ -0,0 +1,73 @@ +# Configuration + +The CustomResourceDefinition (CRD) `eventings.operator.kyma-project.io` describes the Eventing custom resource (CR) in detail. To show the current CRD, run the following command: + + ```shell + kubectl get crd eventings.operator.kyma-project.io -o yaml + ``` + +View the complete [Eventing CRD](https://github.com/kyma-project/eventing-manager/blob/main/config/crd/bases/operator.kyma-project.io_eventings.yaml) including detailed descriptions for each field. + +The CRD is equipped with validation rules and defaulting, so the CR is automatically filled with sensible defaults. You can override the defaults. The validation rules provide guidance when you edit the CR. + +## Examples + +Use the following sample CRs as guidance. Each can be applied immediately when you [install](../contributor/installation.md) Eventing Manager. + +- [Default CR - NATS backend](https://github.com/kyma-project/eventing-manager/blob/main/config/samples/default.yaml) +- [Default CR - EventMesh backend](https://github.com/kyma-project/eventing-manager/blob/main/config/samples/default_eventmesh.yaml) + +## Reference + + + + + + +### Eventing.operator.kyma-project.io/v1alpha1 + +**Spec:** + +| Parameter | Type | Description | +|----------------------------------------------------------|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **annotations** | map\[string\]string | Annotations allows to add annotations to resources. | +| **backend** (required) | object | Backend defines the active backend used by Eventing. | +| **backend.​config** | object | Config defines configuration for eventing backend. | +| **backend.​config.​domain** | string | Domain defines the cluster public domain used to configure the EventMesh Subscriptions and their corresponding ApiRules. | +| **backend.​config.​eventMeshSecret** | string | EventMeshSecret defines the namespaced name of K8s Secret containing EventMesh credentials. The format of name is "namespace/name". | +| **backend.​config.​eventTypePrefix** | string | | +| **backend.​config.​natsMaxMsgsPerTopic** | integer | NATSMaxMsgsPerTopic limits how many messages in the NATS stream to retain per subject. | +| **backend.​config.​natsStreamMaxSize** | \{integer or string\} | NATSStreamMaxSize defines the maximum storage size for stream data. | +| **backend.​config.​natsStreamReplicas** | integer | NATSStreamReplicas defines the number of replicas for stream. | +| **backend.​config.​natsStreamStorageType** | string | NATSStreamStorageType defines the storage type for stream data. | +| **backend.​type** (required) | string | Type defines which backend to use. The value is either `EventMesh`, or `NATS`. | +| **labels** | map\[string\]string | Labels allows to add Labels to resources. | +| **logging** | object | Logging defines the log level for eventing-manager. | +| **logging.​logLevel** | string | LogLevel defines the log level. | +| **publisher** | object | Publisher defines the configurations for eventing-publisher-proxy. | +| **publisher.​replicas** | object | Replicas defines the scaling min/max for eventing-publisher-proxy. | +| **publisher.​replicas.​max** | integer | Max defines maximum number of replicas. | +| **publisher.​replicas.​min** | integer | Min defines minimum number of replicas. | +| **publisher.​resources** | object | Resources defines resources for eventing-publisher-proxy. | +| **publisher.​resources.​claims** | \[\]object | Claims lists the names of resources, defined in spec.resourceClaims, that are used by this container. This is an alpha field and requires enabling the DynamicResourceAllocation feature gate. This field is immutable. It can only be set for containers. | +| **publisher.​resources.​claims.​name** (required) | string | Name must match the name of one entry in pod.spec.resourceClaims of the Pod where this field is used. It makes that resource available inside a container. | +| **publisher.​resources.​limits** | map\[string\]\{integer or string\} | Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ | +| **publisher.​resources.​requests** | map\[string\]\{integer or string\} | Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. Requests cannot exceed Limits. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ | + +**Status:** + +| Parameter | Type | Description | +|------------------------------------------------------|------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **activeBackend** (required) | string | | +| **conditions** | \[\]object | Condition contains details for one aspect of the current state of this API Resource. --- This struct is intended for direct use as an array at the field path .status.conditions. For example, type FooStatus struct{ // Represents the observations of a foo's current state. // Known .status.conditions.type are: "Available", "Progressing", and "Degraded" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type" protobuf:"bytes,1,rep,name=conditions"` | +| // other fields } | | | +| **conditions.​lastTransitionTime** (required) | string | lastTransitionTime is the last time the condition transitioned from one status to another. This should be when the underlying condition changed. If that is not known, then using the time when the API field changed is acceptable. | +| **conditions.​message** (required) | string | message is a human readable message indicating details about the transition. This may be an empty string. | +| **conditions.​observedGeneration** | integer | observedGeneration represents the .metadata.generation that the condition was set based upon. For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date with respect to the current state of the instance. | +| **conditions.​reason** (required) | string | reason contains a programmatic identifier indicating the reason for the condition's last transition. Producers of specific condition types may define expected values and meanings for this field, and whether the values are considered a guaranteed API. The value should be a CamelCase string. This field may not be empty. | +| **conditions.​status** (required) | string | status of the condition, one of `True`, `False`, `Unknown`. | +| **conditions.​type** (required) | string | type of condition in CamelCase or in foo.example.com/CamelCase. --- Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be useful (see .node.status.conditions), the ability to deconflict is important. The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt) | +| **specHash** (required) | integer | | +| **state** (required) | string | | + + diff --git a/docs/user/README.md b/docs/user/README.md index cfd4a40c..540979b1 100644 --- a/docs/user/README.md +++ b/docs/user/README.md @@ -1,6 +1,6 @@ # Eventing module -This module ships the Eventing Manager, which is a standard Kubernetes operator that observes the state of Eventing resources and reconciles them according to the desired state. +This module ships Eventing Manager, which is a standard Kubernetes operator that observes the state of Eventing resources and reconciles them according to the desired state. With Kyma Eventing, you can focus on your business workflows and trigger them with events to implement asynchronous flows within Kyma. Generally, eventing consists of event producers (or publishers) and consumers (or subscribers) that send events to or receive events from an event processing backend. @@ -44,12 +44,21 @@ For more information, read [Eventing architecture](evnt-architecture.md). To learn more about how Eventing works, see: -- [Eventing architecture](evnt-architecture.md) - describes how Eventing works and the main actors involved, such as the Eventing Manager and Event Publisher Proxy. +- [Eventing module](01-manager.md) - provides a general overview of the Eventing module +- [Eventing module configuration](02-configuration.md) - contains information about configuring the Eventing module +- [Eventing architecture](evnt-architecture.md) - describes how Eventing works and the main actors involved, such as Eventing Manager and Event Publisher Proxy. - [Event names](evnt-event-names.md) - contains information about event names and event name cleanup. - [Subscription CR](./resources/evnt-cr-subscription.md) - describes the Subscription custom resource, which you need to subscribe to events. - [CloudEvents](https://cloudevents.io/) - provides information about the CloudEvents specification used in Kyma. - [NATS JetStream](https://docs.nats.io/nats-concepts/jetstream) - provides more information about the backend technology behind Eventing in Kyma. [Eventing Architecture](evnt-architecture.md#jet-stream) provides details on the functionalities and higher qualities of service on top of Core NATS. +To learn more about technical details aimed at possible contributors, check out the following documents: +- [Development](../contributor/development.md) - provides general information about the setup +- [Governance](../contributor/governance.md) - provides information about the rules and norms of this project +- [Installation guide](../contributor/installation.md) - contains information about the different ways to install the Eventing module +- [Testing](../contributor/testing.md) - describes the test coverage of the project +- [Troubleshooting](../contributor/troubleshooting.md) - provides general information about troubleshooting the module + To perform tasks with Eventing, go through these tutorials: - [Tutorial: Trigger your workload with an event](https://kyma-project.io/#/02-get-started/04-trigger-workload-with-event) - shows how to deploy a Function and trigger it with an event.