-
-If you don't see any output, make sure you followed all steps above, with
-correct naming and that all resources (`broker`, `trigger`, `service`, `router`,
-etc.) are in a `READY` state.
\ No newline at end of file
diff --git a/docs/kb/deploy-tanzu-sources-kind.md b/docs/kb/deploy-tanzu-sources-kind.md
new file mode 100644
index 00000000..45e5b320
--- /dev/null
+++ b/docs/kb/deploy-tanzu-sources-kind.md
@@ -0,0 +1,642 @@
+---
+layout: docs
+toc_id: deploy-tanzu-sources-kind
+title: Deploy Tanzu Sources with KinD
+description: Deploy Tanzu Sources with KinD
+permalink: /kb/deploy-tanzu-sources-kind
+---
+
+# Deploy Tanzu Sources with KinD
+
+It is possible to mimic VEBA's base functionalities on your local computer by
+using KinD. KinD, short for "Kubernetes in Docker," is an open-source project
+that provides a lightweight and easy way to create Kubernetes clusters for
+development and testing purposes.
+
+
+## Table of Contents
+
+- [Deploy Tanzu Sources with KinD](#deploy-tanzu-sources-with-kind)
+ - [Prerequisites](#prerequisites)
+ - [Install the Tanzu Sources on KinD](#install-the-tanzu-sources-on-kind)
+ - [Install Event Viewer Application Sockeye](#install-event-viewer-application-sockeye)
+ - [Provider Type vcsim](#provider-type-vcsim)
+ - [Run the vCenter Simulator](#run-the-vcenter-simulator)
+ - [Create a vcsim VSphereSource](#create-a-vcsim-vspheresource)
+ - [Install the govc CLI](#install-the-govc-cli)
+ - [Troubleshooting](#troubleshooting)
+ - [Delete a VSphereSource](#delete-a-vspheresource)
+ - [Delete a HorizonSource](#delete-a-horizonsource)
+ - [Delete a KinD Cluster](#delete-a-kind-cluster)
+
+## Prerequisites
+
+The following prerequisites must be in place:
+
+- [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/) installed
+- Kubernetes CLI
+ [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl) installed
+- Knative CLI [`kn`](https://knative.dev/docs/install/quickstart-install/)
+ installed
+- Knative CLI plugin
+ [quickstart](https://knative.dev/docs/install/quickstart-install/#install-the-knative-quickstart-plugin)
+ installed
+
+The Knative CLI plugin `quickstart` uses `kind` to create a new Kubernetes cluster locally.
+Additionally, it also installs the two Knative subprojects `Serving` and `Eventing`.
+
+**Example:**
+
+```console
+kn quickstart kind --registry
+
+Running Knative Quickstart using Kind
+✅ Checking dependencies...
+ Kind version is: 0.20.0
+💽 Installing local registry...
+☸ Creating Kind cluster...
+Creating cluster "knative" ...
+ ✓ Ensuring node image (kindest/node:v1.26.6) 🖼
+ ✓ Preparing nodes 📦
+ ✓ Writing configuration 📜
+ ✓ Starting control-plane 🕹️
+ ✓ Installing CNI 🔌
+ ✓ Installing StorageClass 💾
+ ✓ Waiting ≤ 2m0s for control-plane = Ready ⏳
+ • Ready after 15s 💚
+Set kubectl context to "kind-knative"
+You can now use your cluster with:
+
+kubectl cluster-info --context kind-knative
+
+Have a nice day! 👋
+
+🍿 Installing Knative Serving v1.12.0 ...
+ CRDs installed...
+ Core installed...
+ Finished installing Knative Serving
+🕸️ Installing Kourier networking layer v1.12.0 ...
+ Kourier installed...
+ Ingress patched...
+ Finished installing Kourier Networking layer
+🕸 Configuring Kourier for Kind...
+ Kourier service installed...
+ Domain DNS set up...
+ Finished configuring Kourier
+🔥 Installing Knative Eventing v1.12.0 ...
+ CRDs installed...
+ Core installed...
+ In-memory channel installed...
+ Mt-channel broker installed...
+ Example broker installed...
+ Finished installing Knative Eventing
+🚀 Knative install took: 2m23s
+🎉 Now have some fun with Serverless and Event Driven Apps!
+```
+
+The above provided output outlines the successful installation of a new
+Kubernetes cluster, with having Knative `Serving` and `Eventing` installed.
+
+Validate the installation:
+
+```console
+kubectl get deploy,po -A
+
+NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
+knative-eventing deployment.apps/eventing-controller 1/1 1 1 63s
+knative-eventing deployment.apps/eventing-webhook 1/1 1 1 63s
+knative-eventing deployment.apps/imc-controller 1/1 1 1 31s
+knative-eventing deployment.apps/imc-dispatcher 1/1 1 1 31s
+knative-eventing deployment.apps/mt-broker-controller 1/1 1 1 21s
+knative-eventing deployment.apps/mt-broker-filter 1/1 1 1 21s
+knative-eventing deployment.apps/mt-broker-ingress 1/1 1 1 21s
+knative-eventing deployment.apps/pingsource-mt-adapter 0/0 0 0 63s
+knative-serving deployment.apps/activator 1/1 1 1 108s
+knative-serving deployment.apps/autoscaler 1/1 1 1 108s
+knative-serving deployment.apps/controller 1/1 1 1 108s
+knative-serving deployment.apps/net-kourier-controller 1/1 1 1 91s
+knative-serving deployment.apps/webhook 1/1 1 1 108s
+kourier-system deployment.apps/3scale-kourier-gateway 1/1 1 1 90s
+kube-system deployment.apps/coredns 2/2 2 2 2m11s
+local-path-storage deployment.apps/local-path-provisioner 1/1 1 1 2m10s
+
+NAMESPACE NAME READY STATUS RESTARTS AGE
+knative-eventing pod/eventing-controller-79547fd7f4-x48pg 1/1 Running 0 63s
+knative-eventing pod/eventing-webhook-8458d5898c-sclpj 1/1 Running 0 63s
+knative-eventing pod/imc-controller-6d55d956f-dlj78 1/1 Running 0 31s
+knative-eventing pod/imc-dispatcher-895bfd847-c8hnj 1/1 Running 0 31s
+knative-eventing pod/mt-broker-controller-6754559b7c-29jvc 1/1 Running 0 21s
+knative-eventing pod/mt-broker-filter-7475984f8-gjm44 1/1 Running 0 21s
+knative-eventing pod/mt-broker-ingress-6786db9bfd-8j67c 1/1 Running 0 21s
+knative-serving pod/activator-8c964665f-wzw5t 1/1 Running 0 108s
+knative-serving pod/autoscaler-5fc869cc5-x545x 1/1 Running 0 108s
+knative-serving pod/controller-5946d56bc-shcsz 1/1 Running 0 108s
+knative-serving pod/net-kourier-controller-d46684575-xdscv 1/1 Running 0 91s
+knative-serving pod/webhook-75d84c68b9-bfmrx 1/1 Running 0 108s
+kourier-system pod/3scale-kourier-gateway-6f84654dc4-klbfc 1/1 Running 0 90s
+kube-system pod/coredns-787d4945fb-79smc 1/1 Running 0 117s
+kube-system pod/coredns-787d4945fb-978th 1/1 Running 0 117s
+kube-system pod/etcd-knative-control-plane 1/1 Running 0 2m11s
+kube-system pod/kindnet-hnhml 1/1 Running 0 117s
+kube-system pod/kube-apiserver-knative-control-plane 1/1 Running 0 2m11s
+kube-system pod/kube-controller-manager-knative-control-plane 1/1 Running 0 2m12s
+kube-system pod/kube-proxy-j8qwh 1/1 Running 0 117s
+kube-system pod/kube-scheduler-knative-control-plane 1/1 Running 0 2m11s
+local-path-storage pod/local-path-provisioner-6bd6454576-v46rk 1/1 Running 0 117s
+```
+
+## Install the Tanzu Sources on KinD
+
+```console
+kubectl apply -f https://github.com/vmware-tanzu/sources-for-knative/releases/latest/download/release.yaml
+```
+
+By default the [Channel based
+Broker](https://knative.dev/docs/eventing/brokers/broker-types/channel-based-broker/)
+is shipped with Knative Eventing. The installation of the KinD cluster also
+includes the creation of an
+[InMemoryChannel](https://github.com/knative/eventing/blob/release-1.12/config/channels/in-memory-channel/README.md)
+broker for event routing.
+
+The broker got installed into the `default` namespace:
+
+```console
+kn broker list
+
+NAME URL AGE CONDITIONS READY REASON
+example-broker http://broker-ingress.knative-eventing.svc.cluster.local/default/example-broker 14m 6 OK / 6 True
+```
+
+```console
+kubectl get broker
+
+NAME URL AGE READY REASON
+example-broker http://broker-ingress.knative-eventing.svc.cluster.local/default/example-broker 14m True
+```
+
+If you would like to receive events from an existing vSphere environment, create a new `VShereSource` like described in section [Create a new VSphereSource via CLI](#create-a-new-vspheresource-via-cli) above.
+
+## Install Event Viewer Application Sockeye
+
+Sockeye lets you view incoming events in the browser, which can be helpful with
+troubleshooting as well as when creating new functions.
+
+Install Sockeye by simply executing `kubectl apply -f https://github.com/n3wscott/sockeye/releases/download/v0.7.0/release.yaml`
+or by applying the following manifest file:
+
+```yaml
+apiVersion: serving.knative.dev/v1
+kind: Service
+metadata:
+ name: sockeye
+ namespace: default
+spec:
+ template:
+ spec:
+ containerConcurrency: 0
+ containers:
+ - image: n3wscott/sockeye:v0.7.0
+```
+
+If not adjusted, the new Knative Service (`ksvc`) will be created in the `default` namespace:
+
+```console
+kn service list
+
+NAME URL LATEST AGE CONDITIONS READY REASON
+sockeye http://sockeye.default.127.0.0.1.sslip.io sockeye-00001 15m 3 OK / 3 True
+```
+
+Update the `ksvc` Sockeye to be not automatically scaled to 0 by Knative:
+
+```console
+kn service update --scale 1 sockeye
+```
+
+This command will set the values for `autoscaling.knative.dev/max-scale` as well
+as for `.../min-scale` to `1`.
+
+In order to ultimately receive events from a `broker`, a `trigger` for Sockeye
+must be created:
+
+```console
+kn trigger create sockeye --broker example-broker --sink ksvc:sockeye
+```
+
+Validate the conditions of the trigger:
+
+```console
+kn trigger list
+
+NAME BROKER SINK AGE CONDITIONS READY REASON
+sockeye example-broker ksvc:sockeye 19m 7 OK / 7 True
+```
+
+You should see incoming events from the vCenter server now. Use the log output
+for this:
+
+```console
+kubectl logs sockeye-00004-deployment-759dc8cffc-p6ttk
+```
+
+**Example:**
+
+```json
+[...]
+Context Attributes,
+ specversion: 1.0
+ type: com.vmware.vsphere.DrsVmPoweredOnEvent.v0
+ source: https://vcsa.mydomain.com/sdk
+ id: 16957152
+ time: 2023-11-27T10:00:08.715999Z
+ datacontenttype: application/json
+Extensions,
+ eventclass: event
+ knativearrivaltime: 2023-11-27T10:00:12.697365304Z
+ vsphereapiversion: 8.0.2.0
+Data,
+ {
+ "Key": 16957152,
+ "ChainId": 16957145,
+ "CreatedTime": "2023-11-27T10:00:08.715999Z",
+ "UserName": "mydomain.com\\Administrator",
+ "Datacenter": {
+ "Name": "DC1",
+ "Datacenter": {
+ "Type": "Datacenter",
+ "Value": "datacenter-1"
+ }
+ },
+ "ComputeResource": {
+ "Name": "Cluster1",
+ "ComputeResource": {
+ "Type": "ClusterComputeResource",
+ "Value": "domain-c8"
+ }
+ },
+ "Host": {
+ "Name": "esx01.mydomain.com",
+ "Host": {
+ "Type": "HostSystem",
+ "Value": "host-15"
+ }
+ },
+ "Vm": {
+ "Name": "vm1",
+ "Vm": {
+ "Type": "VirtualMachine",
+ "Value": "vm-81"
+ }
+ },
+ "Ds": null,
+ "Net": null,
+ "Dvs": null,
+ "FullFormattedMessage": "DRS powered on vm1 on esx01.mydomain.com in DC1",
+ "ChangeTag": "",
+ "Template": false
+ }
+[...]
+```
+
+## Provider Type vcsim
+
+The [vcsim](https://github.com/vmware/govmomi/tree/main/vcsim) provider is a Go
+application to simulate VMware vCenter Server environments.
+
+⚠️ This provider is for experimental usage only! It is limited in its
+functionalities and not comparable with a real VMware vCenter Server
+environment.
+
+### Run the vCenter Simulator
+
+Run the simulator e.g. as a pod on your Kubernetes cluster in a dedicated namespace
+named `ns-vcsim` for example.
+
+Create the new namespace:
+
+```console
+kubectl create ns ns-vcsim
+
+namespace/ns-vcsim created
+```
+
+Instantiate the `vcsim` pod:
+
+```console
+kubectl -n ns-vcsim run vcsim --image=vmware/vcsim:v0.33.0 --port=8989 --image-pull-policy=Always
+
+pod/vcsim created
+```
+
+Create a new Kubernetes `Service` to expose the pod on the cluster:
+
+```console
+kubectl -n ns-vcsim expose pod vcsim
+
+service/vcsim exposed
+```
+
+### Create a vcsim VSphereSource
+
+Create a new `VSphereSource` to receive events from `vcsim`. The source will be
+created within the same namespace `ns-vcsim`.
+
+Begin with the `auth` part like describe before in section [Create a new VSphereSource via CLI](#create-a-new-vspheresource-via-cli).
+
+```console
+kn vsphere auth create \
+--namespace ns-vcsim \
+--username user \
+--password pass \
+--name vcsim-creds \
+--verify-url https://127.0.0.1:8989/sdk \
+--verify-insecure
+```
+
+Create the new `VSphereSource`:
+
+```console
+kn vsphere source create \
+--namespace ns-vcsim \
+--name vcsim-source \
+--vc-address https://vcsim.ns-vcsim:8989/sdk \
+--skip-tls-verify \
+--secret-ref vcsim-creds \
+--sink-uri http://broker-ingress.knative-eventing.svc.cluster.local/default/example-broker \
+--encoding json
+```
+
+Validate the condition of the source:
+
+```console
+kn vsphere source list -n ns-vcsim
+
+NAME VCENTER INSECURE CREDENTIALS AGE CONDITIONS READY REASON
+vcsim-source https://vcsim.ns-vcsim:8989/sdk true vcsim-creds 5m53s 3 OK / 3 True
+```
+
+Additionally, check the logs:
+
+```console
+kubectl -n ns-vcsim logs vcsim-source-adapter-6576ff85fb-s6bbw
+{"level":"warn","ts":"2023-12-05T14:41:45.035Z","logger":"vsphere-source-adapter","caller":"v2/config.go:198","msg":"Tracing configuration is invalid, using the no-op default{error 26 0 empty json tracing config}","commit":"bd08a1c-dirty"}
+{"level":"warn","ts":"2023-12-05T14:41:45.035Z","logger":"vsphere-source-adapter","caller":"v2/config.go:191","msg":"Sink timeout configuration is invalid, default to -1 (no timeout)","commit":"bd08a1c-dirty"}
+{"level":"info","ts":"2023-12-05T14:41:45.051Z","logger":"vsphere-source-adapter","caller":"kvstore/kvstore_cm.go:54","msg":"Initializing configMapKVStore...","commit":"bd08a1c-dirty"}
+{"level":"info","ts":"2023-12-05T14:41:45.057Z","logger":"vsphere-source-adapter","caller":"vsphere/adapter.go:92","msg":"configuring checkpointing","commit":"bd08a1c-dirty","ReplayWindow":"5m0s","Period":"10s"}
+{"level":"warn","ts":"2023-12-05T14:41:45.057Z","logger":"vsphere-source-adapter","caller":"vsphere/adapter.go:131","msg":"could not retrieve checkpoint configuration","commit":"bd08a1c-dirty","error":"key checkpoint does not exist"}
+{"level":"info","ts":"2023-12-05T14:41:45.057Z","logger":"vsphere-source-adapter","caller":"vsphere/adapter.go:311","msg":"no valid checkpoint found","commit":"bd08a1c-dirty"}
+{"level":"info","ts":"2023-12-05T14:41:45.057Z","logger":"vsphere-source-adapter","caller":"vsphere/adapter.go:312","msg":"setting begin of event stream","commit":"bd08a1c-dirty","beginTimestamp":"2023-12-05 14:41:45.057729228 +0000 UTC"}
+```
+
+### Install the govc CLI
+
+[`govc`](https://github.com/vmware/govmomi/tree/master/govc) is used to perform
+operations against the (simulated) vCenter, e.g. powering off a virtual machine
+which will trigger a corresponding event.
+
+```console
+brew install govc
+
+govc about
+govc: specify an ESX or vCenter URL
+```
+
+In a separate terminal create a Kubernetes port-forwarding so we can use `govc`
+to connect to `vcsim` running inside Kubernetes:
+
+```console
+kubectl -n ns-vcsim port-forward pod/vcsim 8989:8989
+
+Forwarding from 127.0.0.1:8989 -> 8989
+Forwarding from [::1]:8989 -> 8989
+```
+
+Open the logs of the instantiated container:
+
+```console
+kubectl -n ns-vcsim logs vcsim
+
+export GOVC_URL=https://user:pass@10.244.0.73:8989/sdk GOVC_SIM_PID=1
+```
+
+If the information above isn't displayed anymore, just replace the pod IP
+address with the one you'll receive from `kubectl -n ns-vcsim get pods -o wide`.
+
+Open another terminal to trigger an event. First, set `govc` environment
+variables (connection):
+
+```console
+# ignore self-signed certificate warnings
+export GOVC_INSECURE=1
+
+# use default credentials and local port-forwarding address
+export GOVC_URL=https://user:pass@127.0.0.1:8989/sdk GOVC_SIM_PID=1
+```
+
+List all available resources of the simulated vSphere environment.
+
+```console
+govc ls
+
+/DC0/vm
+/DC0/host
+/DC0/datastore
+/DC0/network
+```
+
+Trigger an event and observe the output in `Sockeye`:
+
+```console
+govc vm.power -off /DC0/vm/DC0_H0_VM0
+
+Powering off VirtualMachine:vm-55... OK
+```
+
+`Sockeye` should show a `com.vmware.vsphere.VmStoppingEvent.v0` event followed by a `com.vmware.vsphere.VmPoweredOffEvent.v0` event.
+.
+
+```json
+[...]
+
+got Validation: valid
+Context Attributes,
+ specversion: 1.0
+ type: com.vmware.vsphere.VmStoppingEvent.v0
+ source: https://vcsim.ns-vcsim:8989/sdk
+ id: 40
+ time: 2023-12-05T13:06:12.871792908Z
+ datacontenttype: application/json
+Extensions,
+ eventclass: event
+ knativearrivaltime: 2023-12-05T13:06:13.764523682Z
+ vsphereapiversion: 6.5
+Data,
+ {
+ "Key": 40,
+ "ChainId": 40,
+ "CreatedTime": "2023-12-05T13:06:12.871792908Z",
+ "UserName": "user",
+ "Datacenter": {
+ "Name": "DC0",
+ "Datacenter": {
+ "Type": "Datacenter",
+ "Value": "datacenter-2"
+ }
+ },
+ "ComputeResource": {
+ "Name": "DC0_H0",
+ "ComputeResource": {
+ "Type": "ComputeResource",
+ "Value": "computeresource-23"
+ }
+ },
+ "Host": {
+ "Name": "DC0_H0",
+ "Host": {
+ "Type": "HostSystem",
+ "Value": "host-21"
+ }
+ },
+ "Vm": {
+ "Name": "DC0_H0_VM0",
+ "Vm": {
+ "Type": "VirtualMachine",
+ "Value": "vm-55"
+ }
+ },
+ "Ds": {
+ "Name": "LocalDS_0",
+ "Datastore": {
+ "Type": "Datastore",
+ "Value": "datastore-52"
+ }
+ },
+ "Net": null,
+ "Dvs": null,
+ "FullFormattedMessage": "DC0_H0_VM0 on host DC0_H0 in DC0 is stopping",
+ "ChangeTag": "",
+ "Template": false
+ }
+
+[...]
+```
+
+If you don't see any output, make sure you followed all steps above, with
+correct naming and that all resources (`broker`, `trigger`, `service`, `router`,
+etc.) are in a `READY` state.
+
+## Troubleshooting
+
+All components follow the Knative logging convention.
+The log level (`debug`, `info`, `error`, etc. is configurable per component,
+e.g. `vsphere-source-webhook`, `VSphereSource` adapter, etc.
+
+The default logging level is `info`.
+
+The log level for adapters, e.g. a particular `VSphereSource` `deployment` can
+be changed at runtime via the `config-logging` `ConfigMap` which is
+[created](./config/config-logging.yaml) when deploying the Tanzu Sources for
+Knative manifests in this repository.
+
+⚠️ **Note:** These settings will affect **all adapter** (created sources) deployments.
+Changes to a particular adapter deployment are currently not possible.
+
+```console
+kubectl -n vmware-sources edit cm config-logging
+```
+
+An interactive editor opens. Change the settings in the JSON object under the
+`zap-logger-config` key. For example, to change the log level from `info` to
+`debug` use this configuration in the editor:
+
+```yaml
+apiVersion: v1
+data:
+ # details omitted
+ zap-logger-config: |
+ {
+ "level": "debug"
+ "development": false,
+ "outputPaths": ["stdout"],
+ "errorOutputPaths": ["stderr"],
+ "encoding": "json",
+ "encoderConfig": {
+ "timeKey": "ts",
+ "levelKey": "level",
+ "nameKey": "logger",
+ "callerKey": "caller",
+ "messageKey": "msg",
+ "stacktraceKey": "stacktrace",
+ "lineEnding": "",
+ "levelEncoder": "",
+ "timeEncoder": "iso8601",
+ "durationEncoder": "",
+ "callerEncoder": ""
+ }
+ }
+```
+
+Save and leave the interactive editor to apply the `ConfigMap` changes.
+Kubernetes will validate and confirm the changes:
+
+```console
+configmap/config-logging edited
+```
+
+To verify that the `Source` adapter owners (e.g. `vsphere-source-webhook` for a
+`VSphereSource`) have noticed the desired change, inspect the log messages of
+the owner (here: `vsphere-source-webhook`) `Pod`:
+
+```console
+vsphere-source-webhook-f7d8ffbc9-4xfwl vsphere-source-webhook {"level":"info","ts":"2022-03-29T12:25:20.622Z","logger":"vsphere-source-webhook","caller":"vspheresource/vsphere.go:250","msg":"update from logging ConfigMap{snip...}
+```
+
+⚠️ **Note:** To avoid unwanted disruption during event retrieval/delivery, the
+changes are **not applied** automatically to deployed adapters, i.e.
+`VSphereSource` adapter, etc. The operator is in full control over the lifecycle
+(downtime) of the affected `Deployment(s)`.
+
+To make the changes take affect for existing adapter `Deployment`, an operator
+needs to manually perform a rolling upgrade. The existing adapter `Pod` will be
+terminated and a new instanced created with the desired log level changes.
+
+```console
+kubectl get vspheresource
+
+NAME SOURCE SINK READY REASON
+example-vc-source https://my-vc.corp.local http://broker-ingress.knative-eventing.svc.cluster.local/default/example-broker True
+```
+
+```console
+kubectl rollout restart deployment/example-vc-source-adapter
+
+deployment.apps/example-vc-source-adapter restarted
+```
+
+⚠️ **Note:** To avoid losing events due to this (brief) downtime, consider
+enabling the [Checkpointing](#configuring-checkpoint-and-event-replay)
+capability.
+
+
+More details can be found at the Tanzu Sources for Knative repository on Github - [Changing Log Levels](https://github.com/vmware-tanzu/sources-for-knative/tree/main#changing-log-levels).
+
+## Delete a VSphereSource
+
+```console
+kn vsphere source delete --name vcsim-source --namespace ns-vcsim
+```
+
+## Delete a HorizonSource
+
+```console
+kn source delete --name horizon-example --namespace vmware-system
+```
+
+## Delete a KinD Cluster
+
+```code
+kind delete cluster --name knative
+
+Deleting cluster "knative" ...
+Deleted nodes: ["knative-control-plane"]
+```
diff --git a/docs/kb/function-tutorial-deploy.md b/docs/kb/function-tutorial-deploy.md
index 91d9a2f0..271a526d 100644
--- a/docs/kb/function-tutorial-deploy.md
+++ b/docs/kb/function-tutorial-deploy.md
@@ -10,27 +10,36 @@ cta:
actions:
- text: Go back to the Function Tutorial Intro [Function Tutorial - Function Intro](function-tutorial-intro)
- text: Go back to Modify and Test a Function Locally [Function Tutorial - Function Modify and Test](function-tutorial-modtest)
- - text: Look at the [Build Functions](contribute-functions) page for detailed instructions on how to build your own functions.
+ - text: Look at the [Build Functions](contribute-functions) page for detailed instructions on how to build your own functions.
- text: Look at [Troubleshoot Functions](troubleshoot-functions) on help to troubleshoot your functions.
---
-# In-depth function tutorial - Deploy a Function to the VEBA Appliance
+# Function Tutorial - Deploy Functions
This part of the tutorial will go over:
-- Pushing the [kn-ps-slack](https://github.com/vmware-samples/vcenter-event-broker-appliance/tree/master/examples/knative/powershell/kn-ps-slack) Docker container to the DockerHub registry. For this example, we will use the modification we developed in the previous example and will restrict sending a Slack webhook when a Virtual Machine is powered off AND the VM Name starts with "prod".
-- Create a Kubernetes secret that contains the sensitive Slack webhook address.
-- Deploy the [kn-ps-slack](https://github.com/vmware-samples/vcenter-event-broker-appliance/tree/master/examples/knative/powershell/kn-ps-slack) function to the Kubernetes cluster on the VEBA appliance.
-- Verify function operation.
-- Kubernetes troubleshooting commands
+- Pushing the [kn-ps-slack](https://github.com/vmware-samples/vcenter-event-broker-appliance/tree/master/examples/knative/powershell/kn-ps-slack) Docker container to the DockerHub registry. For this example, we will use the modification we developed in the previous example and will restrict sending a Slack webhook when a Virtual Machine is powered off and the VM Name starts with "prod".
+- Creating a Kubernetes secret that contains the sensitive Slack webhook address.
+- Deploying the [kn-ps-slack](https://github.com/vmware-samples/vcenter-event-broker-appliance/tree/master/examples/knative/powershell/kn-ps-slack) function to VEBA.
+- Verifying function operation.
+- Troubleshooting
+
+
## Table of Contents
-- [Push the Docker container to the DockerHub registry](#push-the-docker-container-to-the-dockerhub-registry)
-- [Introduction to the Kubernetes vmware-functions namespace](#introduction-to-the=kubernetes-vmware-functions-namespace)
-- [Deploy kn-ps-slack Function to the VEBA Appliance](#deploy-kn-ps-slack-function-to-the-veba-appliance)
-- [Kubernetes Troubleshooting commands](#kubernetes-troubleshooting-commands)
-## Push the Docker container to the DockerHub registry
+- [Function Tutorial - Deploy Functions](#function-tutorial---deploy-functions)
+ - [Push the Docker Container to the DockerHub Registry](#push-the-docker-container-to-the-dockerhub-registry)
+ - [Introduction to the Kubernetes vmware-functions Namespace](#introduction-to-the-kubernetes-vmware-functions-namespace)
+ - [Deploy kn-ps-slack Function to VEBA](#deploy-kn-ps-slack-function-to-veba)
+ - [Kubernetes Troubleshooting Commands](#kubernetes-troubleshooting-commands)
+ - [kubectl describe](#kubectl-describe)
+ - [kubectl logs](#kubectl-logs)
+ - [kubectl exec](#kubectl-exec)
+ - [kubectl port-forward](#kubectl-port-forward)
+
+## Push the Docker Container to the DockerHub Registry
+
Since we made a change to the code in the `handler.ps1` file that we'd like to use, we will need to push our new Docker container to the DockerHub registry. This will then make it available to be pulled down into VEBA's Kubernetes cluster. The location of the container to use is referenced in the `function.yaml` file:
@@ -49,7 +58,7 @@ spec:
autoscaling.knative.dev/minScale: "1"
spec:
containers:
- - image: ghcr.io/vmware-samples/vcenter-event-broker-appliance/kn-ps-slack:1.4
+ - image: ghcr.io/vmware-samples/vcenter-event-broker-appliance/kn-ps-slack:1.7
envFrom:
- secretRef:
name: slack-secret
@@ -59,12 +68,12 @@ spec:
Note the container image name and the assigned tag. If your company uses a private registry such as [VMware Harbor Registry](https://docs.pivotal.io/vmware-harbor/index.html), the process of pushing your custom Docker image to it will be similar to the example here but may include authentication and a reference to the address of the private registry. When referencing the image in the `function.yaml`, the address of the container image will take the form of:
-```
+
+```console
docker.io/
+
+## Deploy kn-ps-slack Function to VEBA
-## Deploy kn-ps-slack Function to the VEBA Appliance
-1. Move to the `/vcenter-event-broker-appliance/examples/knative/powershell/kn-ps-slack` directory that you cloned earlier with `git`.
+- **Step 1:** Move to the `/vcenter-event-broker-appliance/examples/knative/powershell/kn-ps-slack` directory that you cloned earlier with `git`.
-2. Update the `slack_secret.json` file with your Slack webhook URL.
+- **Step 2:** Update the `slack_secret.json` file with your Slack webhook URL.
-3. Create the Kubernetes secret which can then be accessed from within the function by using the environment variable named `SLACK_SECRET`.
+- **Step 3:** Create the Kubernetes secret which can then be accessed from within the function by using the environment variable named `SLACK_SECRET`.
-```
+```console
# create secret
kubectl -n vmware-functions create secret generic slack-secret --from-file=SLACK_SECRET=slack_secret.json
@@ -163,13 +193,13 @@ kubectl -n vmware-functions label secret slack-secret app=veba-ui
Edit the `function.yaml` file with the name of the custom container image you pushed to DockerHub. For the example listed above, we would use:
-```
+```yaml
spec:
containers:
- image: docker.io/atauber/kn-ps-slack:1.1
```
-By default, the function deployment will filter on the `VmPoweredOffEvent` vCenter server event. If you wish to change this event type, update the subject field within `function.yaml` to the desired event type. The `function.yaml` file is shown below. vCenter server events are described here: [vCenter Events](https://vmweventbroker.io/kb/vcenter-events).
+By default, the function deployment will filter on the `com.vmware.vsphere.VmPoweredOffEvent.v0` vCenter server event. If you wish to change this event type, update the subject field within `function.yaml` to the desired event type. The `function.yaml` file is shown below. vCenter server events are described here: [vCenter Events](https://vmweventbroker.io/kb/vcenter-events).
```yaml
apiVersion: serving.knative.dev/v1
@@ -204,8 +234,7 @@ spec:
broker: default
filter:
attributes:
- type: com.vmware.event.router/event
- subject: VmPoweredOffEvent
+ type: com.vmware.vsphere.VmPoweredOffEvent.v0
subscriber:
ref:
apiVersion: serving.knative.dev/v1
@@ -215,109 +244,134 @@ spec:
Deploy the function to the VEBA Appliance:
-```
+```console
# deploy function
kubectl -n vmware-functions apply -f function.yaml
```
Now with the new function deployed, we should see these resources in the vmware-functions namespace:
-```
+```console
kubectl -n vmware-functions get secret,all
-NAME TYPE DATA AGE
-secret/default-broker-rabbit Opaque 1 14d
-secret/default-token-77dnr kubernetes.io/service-account-token 3 14d
-secret/slack-secret Opaque 1 2m7s
-
-NAME READY STATUS RESTARTS AGE
-pod/default-broker-ingress-5c98bf68bc-mwghj 1/1 Running 0 14d
-pod/kn-ps-slack-00001-deployment-6585d95fff-vl85t 2/2 Running 0 88s
-pod/sockeye-5d7db96f66-shzvp 1/1 Running 0 14d
-pod/sockeye-trigger-dispatcher-7f4dbd7f78-knllr 1/1 Running 0 14d
-pod/veba-ps-slack-trigger-dispatcher-6ccb7479cd-kkdtk 1/1 Running 0 13s
-
-NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-service/default-broker-ingress ClusterIP 10.97.111.83 
-You will also be able to see the alert in Sockeye by searching for the `VmPoweredOffEvent`:
+You will also be able to see the alert in Sockeye by searching for the `com.vmware.vsphere.VmPoweredOffEvent.v0`:
+
+
-
+## Kubernetes Troubleshooting Commands
-## Kubernetes Troubleshooting commands
When things don't work as expected, it is useful to know how to troubleshoot a system. Help in troubleshooting the VEBA appliance and functions can be found here:
-- [Troubleshoot Appliance](troubleshoot-appliance)
-- [Troubleshoot Functions](troubleshoot-functions)
-We have used `kubectl get` and `kubectl apply` in the above examples. The following are some of the more common `kubectl` commands used in troubleshooting.
+- [Troubleshoot Appliance](./troubleshoot-appliance.md)
+- [Troubleshoot Functions](./troubleshoot-functions.md)
+
+We have used `kubectl get` and `kubectl apply` in the above examples. The following are some of the more common `kubectl` commands used in troubleshooting.
-### describe ###
+### kubectl describe
+
The `kubectl describe` command is very useful and shows details about Kubernetes objects like pods. Remember, we need to explicitly set the namespace if not "default".
-```
+```console
kubectl -n vmware-functions get pods
kubectl -n vmware-functions describe pod 
-
- **test** - this directory contains scripts to test and run the VEBA function locally on your workstation, without need for the VEBA appliance.
- **Dockerfile** contains the instructions for the Docker application on how to build the Docker image. You most likely will not need to modify this file.
- **README.md** is the default web page you see at [kn-ps-slack](https://github.com/vmware-samples/vcenter-event-broker-appliance/tree/master/examples/knative/powershell/kn-ps-slack). It is written in markdown language.
- **function.yaml** contains the instructions to load the VEBA function into the Kubernetes cluster. This file has two pieces of information that you may want to change:
- 1. The vCenter Event that triggers the function. The default event is: `VmPoweredOffEvent` but this may be modified to suit your requirements.
+ 1. The vCenter Event that triggers the function. The default event is: `com.vmware.vsphere.VmPoweredOffEvent.v0` but this may be modified to suit your requirements.
2. The location of the Docker image to load into Kubernetes. If the PowerShell code will not be modified, you can leave the default image as is. If you modify the PowerShell code in the handler file, you will need to build a new Docker image and specify the name/location in this file.
- **handler.ps1** contains the PowerShell code that runs when the specified vCenter event triggers it. The `handler.ps1` file is injected into the Docker image which must be rebuilt every time the code changes.
-- **slack_secret.json** contains the Slack key for your Slack channel. This file will be used to create a Kubernetes secret that the function will read. Most functions will include a secret file that contains: usernames/passwords, keys, or other sensitive information that will be used to create a Kubernetes secret.
+- **slack_secret.json** contains the Slack webhook URL for your Slack channel. This file will be used to create a Kubernetes secret that the function will read. Most functions will include a secret file that contains: usernames/passwords, keys, or other sensitive information that will be used to create a Kubernetes secret.
**What are Kubernetes secrets?** The VEBA appliance runs a Kubernetes cluster on top of the Photon OS. This allows the VEBA functions to be packaged as containers that are then deployed into the Kubernetes cluster. A Kubernetes secret is an object that contains a small amount of sensitive data that can be read by a Kubernets pod (pods are made up of one or more containers). Secrets allow sensitive or confidential data to be packaged separate from a container's application code.
## Installing required tools on your workstation
+
You will need to install and configure/use three tools:
- `git` - used to clone the VEBA github repository down to your workstation (including the function code we want to use) so that you have a local copy to modify/test/deploy.
- `docker` - if you modify the function's code, you will use the Docker command line tool to:
@@ -70,16 +74,15 @@ You will need to install and configure/use three tools:
- test the function locally on your workstation without the need for a deployed VEBA appliance.
- `kubectl` - command line interface to the Kubernetes cluster. This command is used to deploy the function and secret to the Kubernetes cluster. It is also used in troubleshooting the VEBA appliance.
-Note: even if the function's code is not modified, Docker will still be necessary to run local tests of the function from your workstation.
+**Note**: Even if the function's code is not modified, Docker will still be necessary to run local tests of the function from your workstation.
Install instructions for the required tools on macOS are below. Install instructions for Windows follow after the macOS instructions.
-
## macOS Instructions
### Install `git` and clone the repo to your workstation
-The following commands will all be run from a macOS terminal (Applications --> Utilities --> Terminal.app).
+The following commands will all be run from a macOS terminal (Applications --> Utilities --> Terminal.app).
Install Homebrew if needed. Homebrew is a package manager for macOS.
```
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
@@ -118,7 +121,7 @@ docker login --username dduck --password VMware1!
### Install and Configure `kubectl`
-`kubectl` is the command line utility used to access a Kubernetes cluster. With `kubectl`, you can deploy the VEBA function in the form of Kubernetes secrets and pods, check logs, and troubleshoot the health of the Kubernetes cluster and VEBA application. The `kubectl` command line utility determines which Kubernetes cluster to access and which certificate to use for authentication by reading a config file. The default config file resides at: `~/.kube/config` on the VEBA appliance.
+Kubectl is the command line utility used to access a Kubernetes cluster. With `kubectl`, you can deploy the VEBA function in the form of Kubernetes secrets and pods, check logs, and troubleshoot the health of the Kubernetes cluster and VEBA application. The `kubectl` command line utility determines which Kubernetes cluster to access and which certificate to use for authentication by reading a config file. The default config file resides at: `~/.kube/config` on the VEBA appliance.
Install `kubectl` with brew:
@@ -129,16 +132,15 @@ kubectl version
Next we will copy the `.kube/config` file from the VEBA appliance to the local workstation. You will need to know the IP address and root password of the deployed VEBA appliance and also verify that SSH has been enabled. These parameters will have been set during the VEBA appliance deployment. Once the config file is copied locally, we will export it so that it becomes the default `kubectl` config file. You can switch which Kubernetes cluster `kubectl` points at by changing the `export KUBECONFIG` file link. This example creates a "veba" folder to store the config file in and uses `scp` to copy the file from the VEBA appliance. Replace 
-**[VMware Event Router](event-router)** implements the core functionality of the VMware Event Broker Appliance, that is connecting to event `streams` ("sources") and processing the events with a configurable event `processor` such as Knative.
+The **[Tanzu Sources for Knative](https://github.com/vmware-tanzu/sources-for-knative)** implements the core functionality of the VMware Event Broker Appliance, that is connecting to event producers and processing the events with a configurable event `processor` such as Knative.
**Knative** is a Kubernetes-based platform to deploy and manage modern serverless workloads. Knative has two core building blocks, that is Serving (Knative Service) and Eventing (Broker, Channel, etc.).
-The VMware Event Router can be configured to directly send events to any addressable Knative resource (“reference”), e.g. a Knative Broker or Service. Broker is the recommended deployment model for the VMware Event Router. Please see the Knative documentation on Eventing for details around brokers, triggers, event filtering, etc.
-Alternatively, the router can send events to a URI, e.g. an external HTTP endpoint accepting CloudEvents.
+The Tanzu Sources (`VSphereSource`, `HorizonSource`) can be configured to directly send events to any addressable Knative resource (`sink`), e.g. a Knative Broker or Service. Broker is the recommended deployment model for a Source. Please see the Knative documentation on Eventing for details around brokers, triggers, event filtering, etc.
+Alternatively, a Source can send events to an URI, e.g. an external HTTP endpoint accepting CloudEvents.
**Contour** is an ingress controller for Kubernetes that works by deploying the Envoy proxy as a reverse proxy and load balancer. Contour supports dynamic configuration updates out of the box while maintaining a lightweight profile. In the VMware Event Broker Appliance, Contour provides **TLS termination for the various HTTP(S) endpoints** served.
@@ -41,14 +41,14 @@ Alternatively, the router can send events to a URI, e.g. an external HTTP endpoi
**Photon OS™** is an open source Linux container host optimized for cloud-native applications, cloud platforms, and VMware infrastructure. Photon OS provides a **secure runtime environment for efficiently running containers** and out of the box support for Kubernetes. Photon OS is the foundation for many appliances built for the vSphere platform and its ecosystem and thus the first choice for building the VMware Event Broker Appliance.
-# Architectural Considerations
+## Architectural Considerations
-Even though the VMware Event Broker Appliance is instantiated as a single running virtual machine, internally its components follow a [microservices architecture](#architecture) running on Kubernetes. The individual services communicate via TCP/IP network sockets. Most of the communication is performed internally in the appliance so the chance of losing network packets is reduced.
+Even though the VMware Event Broker Appliance is instantiated as a single running virtual machine, internally its components follow a [microservices architecture](#architecture) running on Kubernetes. The individual services communicate via TCP/IP network sockets. Most of the communication is performed internally in the appliance so the chance of losing network packets is reduced.
-However, in case of a component becoming unavailable (crash-loop, overloaded,or slow to respond), communication might be impacted and; it's important to understand the consequences for event delivery, i.e. function invocation. To avoid the risk of blocking remote calls, which could render the whole system unusable, sensible default timeouts are applied, which can be fine-tuned if needed.
+However, in case of a component becoming unavailable (crash-loop, overloaded, or slow to respond), communication might be impacted. It's important to understand the consequences for event delivery, i.e. function invocation. To avoid the risk of blocking remote calls, which could render the whole system unusable, sensible default timeouts are applied, which can be fine-tuned if needed.
Kubernetes is a great platform and foundation for building highly available distributed systems. Even though we currently don't make use of its multi-node clustering capabilities (i.e. scale out), Kubernetes provides a lot of benefits to developers and users. Its self-healing capabilities continuously watch the critical VMware Event Broker Appliance components and user-deployed functions and trigger restarts when necessary.
-Kubernetes and its dependencies, such as the Docker, are deployed as systemd units. This addresses the "who watches the watcher" problem in case the Kubernetes node agent (kubelet) or Docker container runtime crashes.
+Kubernetes and its dependencies, such as the containerd, are deployed as systemd units. This addresses the "who watches the watcher" problem in case the Kubernetes node agent (kubelet) or Docker container runtime crashes.
> **Note:** We are considering to use Kubernetes' cluster capabilities in the future to provide increased resiliency (node crashes), scalability (scale out individual components to handle higher load) and durability (replication and persistency). The downside is the added complexity of deploying and managing a multi-node VMware Event Broker Appliance environment.
\ No newline at end of file
diff --git a/docs/kb/intro-event-router.md b/docs/kb/intro-event-router.md
deleted file mode 100644
index 33509fee..00000000
--- a/docs/kb/intro-event-router.md
+++ /dev/null
@@ -1,974 +0,0 @@
----
-layout: docs
-toc_id: intro-event-router
-title: VMware Event Router - Introduction
-description: VMware Event Router Introduction
-permalink: /kb/event-router
-cta:
- title: Get Started
- description: Explore the capabilities that the VMware Event Router enables
- actions:
- - text: Install the [Appliance with Knative](install-knative) to extend your SDDC with our [community-sourced functions](/examples)
- - text: Learn more about the [Events in vCenter](vcenter-events) and how to find the right event for your use case
- - text: Learn more about Functions in this overview [here](functions).
----
-
-# Introduction to VMware Event Router
-
-The VMware Event Router is used to connect to various VMware event `providers`
-(i.e. "sources") and forward these events to different event `processors` (i.e.
-"sinks"). This project is currently used by the [_VMware Event Broker
-Appliance_](https://www.vmweventbroker.io/) as the core logic to forward
-[CloudEvents](https://cloudevents.io/), e.g. from vSphere, to configurable event
-`processors` (see below).
-
-**Supported Event `Providers`:**
-
-- [VMware vCenter Server](https://www.vmware.com/products/vcenter-server.html)
-- [VMware Horizon](https://www.vmware.com/products/horizon.html)
-- Generic [CloudEvents](https://cloudevents.io/) Webhook
-- vCenter Simulator [vcsim](https://github.com/vmware/govmomi/tree/master/vcsim)
- (deprecated, see note [below](#provider-type-vcsim))
-
-**Supported Event `Processors`:**
-
-- [Knative](https://knative.dev/)
-- [OpenFaaS](https://www.openfaas.com/)
-- [AWS EventBridge](https://aws.amazon.com/eventbridge/?nc1=h_ls)
-
-The VMware Event Router uses the [CloudEvents](https://cloudevents.io/) standard
-to normalize events from the supported event `providers`. See
-[below](#example-event-structure) for an example.
-
-**Event `Provider` Delivery Guarantees:**
-
-- At-least-once event delivery
- - with the [vCenter event provider](#provider-type-vcenter) option `checkpoint: true`
-- At-most-once event delivery
- - with the [vCenter event provider](#provider-type-vcenter) option `checkpoint: false`
- - with the [Webhook event provider](#provider-type-webhook)
- - with the [Horizon event provider](#provider-type-horizon)
- - with the [vcsim event provider](#provider-type-vcsim)
-
-> **Note:** All implemented event `processors` use built-in retry mechanisms so
-your function might still be involved multiple times depending on its response
-code. However, if an event `provider` crashes before sending an event to the
-configured `processor` or when the `processor` returns an error, the event is
-not retried and discarded.
-
-**Current limitations:**
-
-- Only one event `provider` and one event `processor` can be configured at a
- time (see note below)
-- At-least-once event delivery semantics are not guaranteed if the event
- router crashes **within seconds** right after startup and having received *n* events but before creating the
- first valid checkpoint (current checkpoint interval is 5s)
-- If an event cannot be successfully delivered (retried) by an event `processor` it is
- logged and discarded, i.e. there is currently no support for [dead letter
- queues](https://en.wikipedia.org/wiki/Dead_letter_queue) (see note below)
-- Retries in the [OpenFaaS event processor](#processor-type-openfaas) are only
- supported when running in synchronous mode, i.e. `async: false` (see this
- OpenFaaS [issue](https://github.com/openfaas/nats-queue-worker/issues/84))
-
-> **Note:** It is possible though to run **multiple instances** of the event
-> router with different configurations to address multi-vCenter scenarios. This
-> decision was made for scalability and resource/tenancy isolation purposes.
-
-> **Note:** Event Processors, like Knative, support Dead Letter Queues when
-> using `Broker` mode.
-
-
-## Table of Contents
-- [Introduction to VMware Event Router](#introduction-to-vmware-event-router)
-- [Configuration](#configuration)
- - [Overview: Configuration File Structure (YAML)](#overview-configuration-file-structure-yaml)
- - [JSON Schema Validation](#json-schema-validation)
- - [API Version, Kind and Metadata](#api-version-kind-and-metadata)
- - [The `eventProvider` section](#the-eventprovider-section)
- - [Provider Type `vcenter`](#provider-type-vcenter)
- - [Provider Type `horizon`](#provider-type-horizon)
- - [Provider Type `webhook`](#provider-type-webhook)
- - [Provider Type `vcsim`](#provider-type-vcsim)
- - [The `eventProcessor` section](#the-eventprocessor-section)
- - [Processor Type `knative`](#processor-type-knative)
- - [Destination](#destination)
- - [Processor Type `openfaas`](#processor-type-openfaas)
- - [Processor Type `aws_event_bridge`](#processor-type-aws_event_bridge)
- - [The `auth` section](#the-auth-section)
- - [Type `basic_auth`](#type-basic_auth)
- - [Type `aws_access_key`](#type-aws_access_key)
- - [Type `aws_iam_role`](#type-aws_iam_role)
- - [Type `active_directory`](#type-active_directory)
- - [The `metricsProvider` section](#the-metricsprovider-section)
- - [Provider Type `default`](#provider-type-default)
-- [Deployment](#deployment)
- - [Assisted Deployment](#assisted-deployment)
- - [Helm Deployment](#helm-deployment)
- - [Option 1: Configuration with Knative](#option-1-configuration-with-knative)
- - [Option 2: Configuration with OpenFaaS](#option-2-configuration-with-openfaas)
- - [Deploy the VMware Event Router Helm Chart](#deploy-the-vmware-event-router-helm-chart)
- - [Creating/Updating the Chart](#creatingupdating-the-chart)
- - [Manual Deployment](#manual-deployment)
- - [Create Knative ClusterRoleBinding (skip if not using Knative)](#create-knative-clusterrolebinding-skip-if-not-using-knative)
- - [Create the VMware Event Router Deployment](#create-the-vmware-event-router-deployment)
- - [CLI Flags](#cli-flags)
-
-# Configuration
-
-The VMware Event Router can be run standalone (statically linked binary) or
-deployed as a Docker container, e.g. in a Kubernetes environment. See
-[deployment](#deployment) for further instructions. The configuration of event
-`providers` and `processors` and other internal components (such as metrics) is
-done via a YAML file passed in via the `-config` command line flag.
-
-```
- _ ____ ___ ______ __ ____ __
-| | / / |/ / ______ _________ / ____/ _____ ____ / /_ / __ \____ __ __/ /____ _____
-| | / / /|_/ / | /| / / __ / ___/ _ \ / __/ | | / / _ \/ __ \/ __/ / /_/ / __ \/ / / / __/ _ \/ ___/
-| |/ / / / /| |/ |/ / /_/ / / / __/ / /___ | |/ / __/ / / / /_ / _, _/ /_/ / /_/ / /_/ __/ /
-|___/_/ /_/ |__/|__/\__,_/_/ \___/ /_____/ |___/\___/_/ /_/\__/ /_/ |_|\____/\__,_/\__/\___/_/
-
-
-Usage of ./vmware-event-router:
-
- -config string
- path to configuration file (default "/etc/vmware-event-router/config")
- -log-json
- print JSON-formatted logs
- -log-level string
- set log level (debug,info,warn,error) (default "info")
-
-commit:
+Each Knative function will have its own pod running in the `vmware-functions` namespace. If you have deployed the provided tagging function example from the [VEBA function examples](https://github.com/vmware-samples/vcenter-event-broker-appliance/tree/development/examples/knative), you can examine the logs with the following command:
-```bash
+```console
kubectl logs -n vmware-functions deployment/kn-pcli-tag-00001-deployment user-container
```
> **Note:** Replace the name of the deployment in the examples with the name within your environment.
-We don't need the `--follow` switch because we are just trying to look at recent logs, but `--follow` would work too.
+First indications of a working function can be obtained directly after deploying a function. For example if a function is successfully connected to a system. The Tagging function for example establishes a connection to the specified vCenter Server system. Here's a log output sample:
+
+```console
+kubectl -n vmware-functions logs kn-pcli-tag-00001-deployment-6d6db78495-bdz8j
+
+Defaulted container "user-container" out of: user-container, queue-proxy
+01/17/2024 10:34:57 - PowerShell HTTP server start listening on 'http://*:8080/'
+01/17/2024 10:34:57 - Processing Init
+
+01/17/2024 10:34:57 - Configuring PowerCLI Configuration Settings
+
+
+DefaultVIServerMode : Multiple
+ProxyPolicy : UseSystemProxy
+ParticipateInCEIP : True
+CEIPDataTransferProxyPolicy : UseSystemProxy
+DisplayDeprecationWarnings : True
+InvalidCertificateAction : Ignore
+WebOperationTimeoutSeconds : 300
+VMConsoleWindowBrowser :
+Scope : Session
+PythonPath : /usr/local/bin/python3
+
+DefaultVIServerMode :
+ProxyPolicy :
+ParticipateInCEIP : True
+CEIPDataTransferProxyPolicy :
+DisplayDeprecationWarnings :
+InvalidCertificateAction : Ignore
+WebOperationTimeoutSeconds :
+VMConsoleWindowBrowser :
+Scope : User
+PythonPath :
+
+DefaultVIServerMode :
+ProxyPolicy :
+ParticipateInCEIP :
+CEIPDataTransferProxyPolicy :
+DisplayDeprecationWarnings :
+InvalidCertificateAction :
+WebOperationTimeoutSeconds :
+VMConsoleWindowBrowser :
+Scope : AllUsers
+PythonPath : /usr/local/bin/python3
+
+01/17/2024 10:35:02 - Connecting to vCenter Server vcsa.jarvis.lab
+
+IsConnected : True
+Id : /VIServer=vsphere.local\administrator@vcsa.jarvis.lab:443/
+ServiceUri : https://vcsa.jarvis.lab/sdk
+SessionSecret : "a58cfe1ebd168aff2345ab80c0a1343ae4414c3d"
+Name : vcsa.jarvis.lab
+Port : 443
+SessionId : "a58cfe1ebd168aff2345ab80c0a1343ae4414c3d"
+User : VSPHERE.LOCAL\Administrator
+Uid : /VIServer=vsphere.local\administrator@vcsa.jarvis.lab:443/
+Version : 8.0.2
+Build : 22617221
+ProductLine : vpx
+InstanceUuid : 60b82abd-ba3b-4114-825b-d48c1bdd5dea
+RefCount : 1
+ExtensionData : VMware.Vim.ServiceInstance
+
+01/17/2024 10:35:07 - Successfully connected to vcsa.jarvis.lab
+
+01/17/2024 10:35:07 - Init Processing Completed
+
+01/17/2024 10:35:07 - Starting HTTP CloudEvent listener
+```
+
+If a function got correctly invoked can be seen via the logs as well after the specified event occured.
This command will show you the last 5 minutes worth of logs.
-```bash
-kubectl logs -n vmware-functions deployment/kn-pcli-tag-00001-deployment user-container --since=5m
+```console
+kubectl -n vmware-functions logs deployment/kn-pcli-tag-00001-deployment user-container --since=5m
```
This command will show you the last 20 lines of logs.
-```bash
-kubectl logs -n vmware-functions deployment/kn-pcli-tag-00001-deployment user-container --tail=20
+```console
+kubectl -n vmware-functions logs deployment/kn-pcli-tag-00001-deployment user-container --tail=20
```
Log output showing a successful function invocation:
-```
-09/24/2021 13:57:05 - Applying vSphere Tag "VEBA" to My-VEBA-Test-VM ...
+```console
+01/17/2024 10:37:41 - Applying vSphere Tag "backup-sla" to workload1 ...
-09/24/2021 13:57:09 - vSphere Tag Operation complete ...
+01/17/2024 10:37:51 - vSphere Tag Operation complete ...
-09/24/2021 13:57:09 - Handler Processing Completed ...
+01/17/2024 10:37:51 - Handler Processing Completed ...
```
diff --git a/docs/kb/use-eventspec.md b/docs/kb/use-eventspec.md
index 1f29a9f1..12939435 100644
--- a/docs/kb/use-eventspec.md
+++ b/docs/kb/use-eventspec.md
@@ -16,7 +16,7 @@ cta:
The event payload structure used by the VMware Event Broker Appliance uses the
[CloudEvents](https://cloudevents.io/){:target="_blank"} v1 specification for
-cross-cloud portability.
+cross-cloud portability.
Events produced by the supported event `providers`, e.g. `vcenter` and `horizon`
are JSON-encoded and injected into the CloudEvents `data` attribute. The current
@@ -33,6 +33,15 @@ the event `provider`, e.g. `vcenter`.
Please use one of the provided CloudEvents [SDKs](https://cloudevents.io/) to
ease the consumption and handling of these events.
+
+## Table of Contents
+
+- [The Event Specification](#the-event-specification)
+ - [Example](#example)
+ - [HTTP Headers](#http-headers)
+ - [Description](#description)
+ - [HTTP Body](#http-body)
+
## Example
The following example shows a converted CloudEvent published by the `vcenter`
@@ -48,9 +57,8 @@ Key HTTP headers used:
"Ce-Id": "08179137-b8e0-4973-b05f-8f212bf5003b",
"Ce-Source": "https://vcenter-01:443/sdk",
"Ce-Specversion": "1.0",
- "Ce-Subject": "VmPoweredOnEvent",
"Ce-Time": "2021-09-27T19:02:54.063Z",
- "Ce-Type": "com.vmware.event.router/event",
+ "Ce-Type": "com.vmware.vsphere.
diff --git a/docs/site/faq.md b/docs/site/faq.md
index 1999025c..af20d004 100644
--- a/docs/site/faq.md
+++ b/docs/site/faq.md
@@ -10,30 +10,30 @@ faqs:
items:
- Q: Can I connect to more than one vCenter per Appliance deployment?
A: >
- No. The Appliance is currently designed to support one vCenter as the event source. Customers that are familiar with deploying the components on Kubernetes can deploy multiple instances of the VMware Event Router container.
+ No. During the deployment of the VMware Event Broker Appliance to vSphere, only one vSphere source and one Horizon source can be configured at a time.
- > **Note:** It is possible though to run **multiple instances** of the event router with different configurations to address multi-vCenter scenarios.
+ > **Note:** It is possible though to run multiple instances of a source (e.g. `VSphereSource`) with different configurations to address multi-vCenter scenarios. This decision was made for scalability and resource/tenancy isolation purposes.
- Q: Can the default TLS certificates that are being used on the Appliance be updated?
A: Yes! Follow the steps provided [here](/kb/advanced-certificates).
- Q: What happens if vCenter Server and VMware Event Broker connectivity is lost?
A: >
- VMware [Event Router](https://vmweventbroker.io/kb/event-router) streams vCenter events as they get generated and being stateless, does not persist any event information. To provide a certain level of reliability, the following Event Delivery Guarantees exists:
- - At-least-once event delivery semantics for the vCenter event provider by checkpointing the event stream into a file. In case of disconnection, the Event Router will replay all vCenter events of the last 10 minutes (10m reiteration) after a successful reconnection.
- - At-least-once event delivery semantics are not guaranteed if the event router crashes within seconds right after startup and having received *n* events but before creating the first valid checkpoint (current checkpoint interval is 5s).
+ A configured VMware [Tanzu Source](https://vmweventbroker.io/kb/tanzu-sources) streams vCenter events as they get generated and being stateless, does not persist any event information. To provide a certain level of reliability, the following Event Delivery Guarantees exists:
+ - **At-least-once event delivery** semantics for the vCenter event provider by checkpointing the event stream into a file. In case of disconnection, the Event Router will replay all vCenter events of the last 5 minutes (5m reiteration) after a successful reconnection.
+ - **At-least-once event delivery** semantics are not guaranteed if the source-adapter (pod) crashes within seconds right after startup and having received *n* events but before creating the first valid checkpoint (current checkpoint interval is 10s).
- Q: How long does it take for the functions to be invoked upon an event being generated? A: Instantaneous to a few seconds! The function execution itself is not considered in this answer since that is dependent on the logic that is being implemented. - Q: Can I setup the VMware Event Broker Appliance components on Kubernetes? - A: Yes! Follow the steps provided [here](/kb/event-router#deployment). + A: Yes! Follow the steps provided [here](/kb/tanzu-sources#installation-tanzu-sources-for-knative). - Q: Can I use a private registry like e.g. [Harbor](https://goharbor.io/) to have a source of truth for my functions (images)? A: Yes! Follow the steps provided [here](https://vmweventbroker.io/kb/private-registry). - Q: How can I monitor the Appliance, the Kubernetes components as well as the functions (pods) in terms of utilization, performance and state? - A: vRealize Operations Manager provides these capabilities as described [here](https://rguske.github.io/post/monitoring-the-vmware-event-broker-appliance-with-vrealize-operations-manager/). + A: VMware Aria Operations provides these capabilities as described [here](https://docs.vmware.com/en/VMware-vRealize-Operations-Management-Pack-for-Kubernetes/1.8/management-pack-for-kubernetes/GUID-4ED07321-A5C9-46D6-8EB0-2661D853C0E9.html). - title: Common Questions - Functions id: function items: - Q: How do I obtain the Events in the function? A: > - Events are made available as stdin argument for the language that you are writing the function on. For example,
+ Events are made available as `stdin` argument for the language that you are writing the function on. For example,
- In Powershell the event is made available using the `$args` variable as shown here `$json = $args | ConvertFrom-Json`
- In Python the event is made available with the `req` variable as shown here `cevent = json.loads(req)` - Q: How do I obtain the config file within the function? @@ -73,6 +73,5 @@ Find answers to the frequently asked questions about VMware Event Broker Applian - Explore our [documentation](/kb) - Feel free to reach out - Email us at [dl-veba@vmware.com](mailto:dl-veba@vmware.com){:target="_blank"} - - Join us on slack [#vcenter-event-broker-appliance](https://vmwarecode.slack.com/archives/CQLT9B5AA){:target="_blank"} on vmwarecode.slack.com - Tweet at us [@VMWEventBroker](https://twitter.com/VMWEventBroker){:target="_blank"} - Explore our Github repository [here](https://github.com/vmware-samples/vcenter-event-broker-appliance){:target="_blank"} \ No newline at end of file
- - At-least-once event delivery semantics for the vCenter event provider by checkpointing the event stream into a file. In case of disconnection, the Event Router will replay all vCenter events of the last 10 minutes (10m reiteration) after a successful reconnection.
- - At-least-once event delivery semantics are not guaranteed if the event router crashes within seconds right after startup and having received *n* events but before creating the first valid checkpoint (current checkpoint interval is 5s).
+ A configured VMware [Tanzu Source](https://vmweventbroker.io/kb/tanzu-sources) streams vCenter events as they get generated and being stateless, does not persist any event information. To provide a certain level of reliability, the following Event Delivery Guarantees exists:
+ - **At-least-once event delivery** semantics for the vCenter event provider by checkpointing the event stream into a file. In case of disconnection, the Event Router will replay all vCenter events of the last 5 minutes (5m reiteration) after a successful reconnection.
+ - **At-least-once event delivery** semantics are not guaranteed if the source-adapter (pod) crashes within seconds right after startup and having received *n* events but before creating the first valid checkpoint (current checkpoint interval is 10s).
- Q: How long does it take for the functions to be invoked upon an event being generated? A: Instantaneous to a few seconds! The function execution itself is not considered in this answer since that is dependent on the logic that is being implemented. - Q: Can I setup the VMware Event Broker Appliance components on Kubernetes? - A: Yes! Follow the steps provided [here](/kb/event-router#deployment). + A: Yes! Follow the steps provided [here](/kb/tanzu-sources#installation-tanzu-sources-for-knative). - Q: Can I use a private registry like e.g. [Harbor](https://goharbor.io/) to have a source of truth for my functions (images)? A: Yes! Follow the steps provided [here](https://vmweventbroker.io/kb/private-registry). - Q: How can I monitor the Appliance, the Kubernetes components as well as the functions (pods) in terms of utilization, performance and state? - A: vRealize Operations Manager provides these capabilities as described [here](https://rguske.github.io/post/monitoring-the-vmware-event-broker-appliance-with-vrealize-operations-manager/). + A: VMware Aria Operations provides these capabilities as described [here](https://docs.vmware.com/en/VMware-vRealize-Operations-Management-Pack-for-Kubernetes/1.8/management-pack-for-kubernetes/GUID-4ED07321-A5C9-46D6-8EB0-2661D853C0E9.html). - title: Common Questions - Functions id: function items: - Q: How do I obtain the Events in the function? A: > - Events are made available as stdin argument for the language that you are writing the function on. For example,
+ Events are made available as `stdin` argument for the language that you are writing the function on. For example,
- In Powershell the event is made available using the `$args` variable as shown here `$json = $args | ConvertFrom-Json`
- In Python the event is made available with the `req` variable as shown here `cevent = json.loads(req)` - Q: How do I obtain the config file within the function? @@ -73,6 +73,5 @@ Find answers to the frequently asked questions about VMware Event Broker Applian - Explore our [documentation](/kb) - Feel free to reach out - Email us at [dl-veba@vmware.com](mailto:dl-veba@vmware.com){:target="_blank"} - - Join us on slack [#vcenter-event-broker-appliance](https://vmwarecode.slack.com/archives/CQLT9B5AA){:target="_blank"} on vmwarecode.slack.com - Tweet at us [@VMWEventBroker](https://twitter.com/VMWEventBroker){:target="_blank"} - Explore our Github repository [here](https://github.com/vmware-samples/vcenter-event-broker-appliance){:target="_blank"} \ No newline at end of file