vmware-samples / vcenter-event-broker-appliance

The VMware Event Broker Appliance Fling enables customers to unlock the hidden potential of events in their SDDC to easily create event-driven automation.

VMware Event Broker Appliance

Table of Contents

• VMware Event Broker Appliance
  • Table of Contents
  • Getting Started
  • Overview
  • Architecture
  • Getting in touch
  • Contributing
  • License

Getting Started

Visit our website vmweventbroker.io and explore our documentation to get started quickly.

Overview

The VMware Event Broker Appliance Fling enables customers to unlock the hidden potential of events in their SDDC to easily create event-driven automation. The VMware Event Broker Appliance includes support for vCenter Server and VMware Horizon events as well as any valid CloudEvent through the native webhook event provider. Easily triggering custom or prebuilt actions to deliver powerful integrations within your datacenter across public cloud has never been more easier before. A detailed list of use cases and possibilities with VMware Event Broker Appliance is available here

With this solution, end-users, partners and independent software vendors only have to write minimal business logic without going through a steep learning curve understanding the vSphere or Horizon APIs. As such, we believe this solution not only offers a better user experience in solving existing problems for VI/Cloud Admins, SRE/Operators, Automation Engineers and 3rd Party Vendors. More importantly, it will enable new integration use cases and workflows to grow the VMware ecosystem and community, similar to what AWS has achieved with AWS Lambda.

Learn more about the VMware Event Broker Appliance here.

Additional resources can be found here and some quick references are highlighted below.

• Watch Michael Gasch and William Lam present a session at VMware {Code} called VEBA Revolutions - Unleashing the Power of Event-Driven Automation.
• Listen to William Lam talking about Event-Driven Automation with Project VEBA in Episode #006 of the Unexplored Territory podcast.
• Watch Robert Guske present a session at ContainerDays 2023 called Embark on a Transformative Odyssey - Event-Driven Automation Unveiled through Knative.
• Watch Michael Gasch and Steven Wong present a session at KubeCon EU 2022 called Optimize Kubernetes on vSphere with Event-Driven Automation.

Architecture

VMware Event Broker Appliance is provided as a Virtual Appliance that can be deployed to any vSphere-based infrastructure, including an on-premises and/or any public cloud environment running on vSphere.

The VMware Event Broker Appliance follows a highly modular approach, using Kubernetes and containers as an abstraction layer between the base operating system (Photon OS) and the required application services. Currently the following components are used in the appliance:

• Tanzu Sources for Knative (Github)
  • Supported Event Stream Sources:
    • VMware vCenter (Website)
    • VMware Horizon (Website)
    • Incoming Webhooks
  • Supported Event Stream Processors:
    • Knative (Website)
• Contour (Github)
• Kubernetes (Github)
• Photon OS (Github)

For more details about the individual components and how they are used in the VMware Event Broker Appliance, please see the Architecture page.

Getting in touch

Feel free to reach out to Team #VEBA

• Email us at [email protected]
• Follow for updates @VMWEventBroker

Contributing

The VMware Event Broker Appliance team welcomes contributions from the community.

To help you get started making contributions to VMware Event Broker Appliance, we have collected some helpful best practices in the Contributing guidelines.

Before submitting a pull request, please make sure that your change satisfies the requirements specified here

License

VMware Event Broker Appliance is available under the BSD-2 license. Please see LICENSE.txt.

vcenter-event-broker-appliance's Issues

Examples should not use personal Docker accounts

We should automate the build of user-provided examples to better verify image content and functionality.

This requires:

• Updates to the contribution guide (how to submit an example with this repo's build account)
• Repository/account for the builds
• Automated builds for images provided via PRs

Plugin Model for Outbound Webhooks

After reviewing the work done by @opvizordz in b35a3e2, it occured to me that it may be worth exploring a plugin model for the outbound webhooks. This will let anyone contribute a plugin for their chat platform of choice, and any new functions could re-use this code.

I am probably not the right person to implement the framework, but I could contribute some plugins.

Suggestions:

• Microsoft Teams
• WebEx Teams
• Discord
• Telegram
• ???

We use WebEx Teams at work and I could test my home lab against Discord, so I could potentially work on those.

Consistent user experience for example functions

Check functions provided as examples for consistency on:

• docs
• events used (e.g. standardize on "DrsVmPoweredOnEvent,VmPoweredOnEvent") to address common issues in non-DRS enabled clusters
• naming (values in stack.yml, e.g. handlers, secrets, etc.)

Build errors due to stricter linting

make
[...]
Step 11/24 : RUN ./bin/golangci-lint run ./...
 ---> Running in 8ac534104979
internal/metrics/server.go:113:11: Error return value of `w.Write` is not checked (errcheck)
                        w.Write([]byte("invalid credentials"))
                               ^
cmd/main.go:150:26: Error return value of `streamer.Shutdown` is not checked (errcheck)
                defer streamer.Shutdown(egCtx)
                                       ^
internal/metrics/server.go:135:19: SA1015: using time.Tick leaks the underlying ticker, consider using it only in endless functions, tests and the main package, and use time.NewTicker here (staticcheck)
                case <-time.Tick(time.Second):
                                ^
internal/processor/aws_event_bridge.go:326:19: SA1015: using time.Tick leaks the underlying ticker, consider using it only in endless functions, tests and the main package, and use time.NewTicker here (staticcheck)
                case <-time.Tick(metrics.PushInterval):
                                ^
internal/processor/openfaas.go:161:19: SA1015: using time.Tick leaks the underlying ticker, consider using it only in endless functions, tests and the main package, and use time.NewTicker here (staticcheck)
                case <-time.Tick(metrics.PushInterval):
                                ^
internal/processor/aws_event_bridge.go:137:5: S1023: redundant break statement (gosimple)
                                break
                                ^
internal/processor/aws_event_bridge.go:301:5: S1023: redundant break statement (gosimple)
                                break
                                ^
internal/processor/aws_event_bridge.go:145:8: S1002: should omit comparison to bool constant, can be simplified to `found` (gosimple)
                case found == true: // return early
                     ^
internal/processor/aws_event_bridge.go:309:8: S1002: should omit comparison to bool constant, can be simplified to `found` (gosimple)
                case found == true: // return early
                     ^
internal/processor/aws_event_bridge.go:222:41: printf: Wrapf format %s has arg event.GetEvent().Key of wrong type int32 (govet)
                        return eventbridge.PutEventsInput{}, errors.Wrapf(err, "could not marshal cloud event for vSphere event %s from source %s", event.GetEvent().Key, awsEventBridge.source)
                                                             ^
internal/processor/openfaas.go:151:19: printf: Wrapf format %s has arg event.GetEvent().Key of wrong type int32 (govet)
                return "", nil, errors.Wrapf(err, "could not marshal cloud event for vSphere event %s from source %s", event.GetEvent().Key, source)
                                ^
The command '/bin/sh -c ./bin/golangci-lint run ./...' returned a non-zero code: 1
make: *** [build] Error 1

HTTPS Proxy config assumes "https://" prefix

The HTTPS Proxy assumes that an "https://" prefix is required. With squid proxies this is not the case, and as such I initially was not able to run kubectl get pods -A as it returned an error about the proxy. Once I fixed that in /etc/sysconfig/proxy and rebooted I was then not able to deploy the echo function as Docker couldn't pull the image. After adjusting /etc/systemd/system/docker.service.d//https-proxy.conf and rebooting again all works as expected.

Suggest adjusting the OVF property descriptions to allow the addition of the http(s):// prefix, and adjusting setup-02-proxy.sh to use a prefix if defined and optionally insert the username/password.

I've submitted a PR #139 that suggests a way of acheiving this. I'm not sure where to edit the OVF properties descriptions however.

Support all vCenter events

Currently only a subset of vCenter (core) events are supported. Support any core event, e.g. session login and EventEx/ExtendedEvent types.

Support more than one rule in AWS EventBridge Processor

Today vmware-event-router only supports one event bus and one associated event rule in the configuration file:

{...
        "options": {
            "aws_region": "eu-central-1",
            "aws_eventbridge_event_bus": "default",
            "aws_eventbridge_rule_arn": "arn:aws:events:eu-central-1:1234567890:rule/vmware-event-router"
        }

In order to support multiple rules, we could remove the option "aws_eventbridge_rule_arn" and ask customers to create a dedicated event bus used by the vmware-event-router. The vmware-event-router would list and use all rules associated to that bus and use the current logic of details.data.subjectto retrieve the events to be forwarded to AWS.

Clarify resync of EventBridge rules in docs

OpenFaaS password is using root password not admin

Customer found that they were not able to login to OpenFaaS UI using the admin password they had set. Upon troubleshooting, I found that the code was actually referencing the root password instead of the admin password which needs to be fixed.

Support TTL and max retries in event metadata

Similar to the recent improvements in AWS Lambda it might be useful to have configurable time-to-live and maxRetryAttempts in the outgoing event payload. To quote from the AWS Lambda announcement:

Maximum Event Age

When a function returns an error before execution, Lambda returns the event to the queue and attempts to run the function again for up to 6 hours by default. With Maximum Event Age, you can configure the lifetime of an event in the queue from 60 seconds to 6 hours. This allows you to remove any unwanted events based on the event age.

Maximum Retry Attempts

When a function returns an error after execution, Lambda attempts to run it two more times by default. With Maximum Retry Attempts, you can customize the maximum number of retries from 0 to 2. This gives you the option to continue processing new events with fewer or no retries.

With these two features, events are discarded, or sent to a dead-letter queue and/or Lambda destinations when one of these two conditions is met: Retry Attempts reaches its maximum value, or Event Age reaches its maximum value.
Source: https://aws.amazon.com/about-aws/whats-new/2019/11/aws-lambda-supports-max-retry-attempts-event-age-asynchronous-invocations/

Create Helm chart for Event Router

Make it easier for users deploying vmware-event-router directly (on Kubernetes) by providing a Helm chart.Evaluate options for air-gapped deployments.

Multiple DNS name support

I don't know which component prevents an https response if the URL doesn't precisely match the hostname entered upon deployment of the appliance. But if you deploy veba01, browsing to the FQDN of veba01.foo.com fails. Or if you deploy veba01.foo.com, you cannot browse to veba01. You get a connection reset error.

We have lots of situations at larger customers where they have VMs sitting behind a NAT with split DNS, so a device might be veba01.foo.com the outside but veba01.domain.com on the inside.

I'm not sure what's easier - if there's just 1 setting at deploy time where we can just 'allow all domains' and VEBA responds to any request, that's great. Or, if we have the ability to specify an alternative DNS name where the VEBA would respond to both DNS Names, then add those domains to the certificate as SAN names, that would work too.

Update function examples for new CloudEvents spec

Add NTP configuration to OVF deployment

Troubleshooting events in VEBA is difficult without accurate timesync. Suggest changing the OVF to accept NTP server configuration.

1. Installation GUI accepts a space-separated list of NTP servers.
   Example: 192.168.203.1 192.168.200.1

2. Installer updates /etc/systemd/timesyncd.conf
   Example:

[Time]
NTP=192.168.203.1 192.168.200.1

Enable customization of Docker networks

Please can we enable the customization of the Docker network?

Currently, anyone of 172.17.0.0/16 is unable to deploy the appliance.

Due to the popularity of this CIDR block I imagine the prevents a number of customers from trying out this fling.

Reorganize and clean up /root directory

All VEBA configuration files are created in /root which makes it a bit messy for anyone logging in for the first time. Will move all these files into /root/config

Allow network proxy settings during deployment

Issues deploying to air-gapped environment.

As discussed in the Slack channel, I am having issues deploying v0.3 to an air-gapped network as some images are not available at the correct version locally. For example weave-kube and weave-npc v2.6.1 are not available.

root@rktest01 [ ~ ]# docker image list
REPOSITORY                           TAG                 IMAGE ID            CREATED             SIZE
vmware/veba-event-router             latest              40af0186f445        3 weeks ago         119MB
k8s.gcr.io/kube-proxy                v1.14.9             636041c2a488        4 months ago        82.1MB
k8s.gcr.io/kube-apiserver            v1.14.9             5811259ed0c9        4 months ago        209MB
k8s.gcr.io/kube-controller-manager   v1.14.9             07193a77f264        4 months ago        157MB
k8s.gcr.io/kube-scheduler            v1.14.9             0f036524b7a2        4 months ago        81.6MB
weaveworks/weave-npc                 2.6.0               5105e13e253e        5 months ago        34.9MB
weaveworks/weave-kube                2.6.0               174e0e8ef23d        5 months ago        114MB

root@rktest01 [ ~ ]# kubectl get events -n kube-system
38m         Normal    LeaderElection      endpoints/kube-scheduler               rktest01_1796a1b4-77e8-11ea-8ed2-005056b993a7 became leader
38m         Normal    Scheduled           pod/weave-net-5tqhs                    Successfully assigned kube-system/weave-net-5tqhs to rktest01
37m         Normal    Pulling             pod/weave-net-5tqhs                    Pulling image "docker.io/weaveworks/weave-kube:2.6.1"
36m         Warning   Failed              pod/weave-net-5tqhs                    Failed to pull image "docker.io/weaveworks/weave-kube:2.6.1": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
36m         Warning   Failed              pod/weave-net-5tqhs                    Error: ErrImagePull
36m         Normal    Pulling             pod/weave-net-5tqhs                    Pulling image "docker.io/weaveworks/weave-npc:2.6.1"
36m         Warning   Failed              pod/weave-net-5tqhs                    Failed to pull image "docker.io/weaveworks/weave-npc:2.6.1": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
36m         Warning   Failed              pod/weave-net-5tqhs                    Error: ErrImagePull
13m         Normal    BackOff             pod/weave-net-5tqhs                    Back-off pulling image "docker.io/weaveworks/weave-kube:2.6.1"
3m5s        Warning   Failed              pod/weave-net-5tqhs                    Error: ImagePullBackOff
37m         Normal    BackOff             pod/weave-net-5tqhs                    Back-off pulling image "docker.io/weaveworks/weave-npc:2.6.1"
36m         Warning   Failed              pod/weave-net-5tqhs                    Error: ImagePullBackOff
38m         Normal    SuccessfulCreate    daemonset/weave-net                    Created pod: weave-net-5tqhs

After manually pulling the correct weave images and restarting the appliance I am still not quite there. I am now getting a similar issue with the veba-event-router image.

root@rktest01 [ ~ ]# kubectl get events -n vmware
LAST SEEN   TYPE      REASON              OBJECT                                      MESSAGE
8m12s       Normal    Scheduled           pod/vmware-event-router-5dd9c8f858-cf4qs    Successfully assigned vmware/vmware-event-router-5dd9c8f858-cf4qs to rktest01
5m59s       Normal    Pulling             pod/vmware-event-router-5dd9c8f858-cf4qs    Pulling image "vmware/veba-event-router:latest"
5m44s       Warning   Failed              pod/vmware-event-router-5dd9c8f858-cf4qs    Failed to pull image "vmware/veba-event-router:latest": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
5m44s       Warning   Failed              pod/vmware-event-router-5dd9c8f858-cf4qs    Error: ErrImagePull
5m31s       Normal    BackOff             pod/vmware-event-router-5dd9c8f858-cf4qs    Back-off pulling image "vmware/veba-event-router:latest"
2m57s       Warning   Failed              pod/vmware-event-router-5dd9c8f858-cf4qs    Error: ImagePullBackOff

Update: It looks like the issue with the veba-event-router image is that it is set to use the :latest tag which I believe is automatically setting the Image Pull Policy to Always.

Entering http ProxyUrl for https not possible

Hi VEBA Support:
There is no way to enter a https Proxy Url with an http Proxy Url
https_proxy=http://myhost:3128
Prio: low

Support Webhooks

Upgrade version of Contour

Move from IngressRoute to HTTPProxy and also keep up with latest release (security fixes) https://projectcontour.io/hot-reload-certificates-safely-rollout-envoy-contour-1.2/

Stricter Release Management

The project is growing with more users and contributors. In order to ensure a good user experience, i.e. don't break installations due to out of sync master/release, we need to improve our release process.

I propose a Github dev/release process as described in the diagram below (details here):

Detailed writeup of the diagram above here.

The following changes to the repository structure/documentation are required:

• Create "development" branch - @embano1
• Update contributors guide with PR instructions - @embano1
• Create PR template for contributors - @embano1
• Automated appliance deployment - @lamw
• Automated regression tests (deploy appliance, test a set of function) - @lamw

Please provide feedback/missing action items so we can start with a more streamlined release process.

@lamw @vladi-velikov @martindekov

Improve VEBA DCUI error cases

1. If /etc/veba-release file is missing entries, DCUI will not load causing blank screen in console
2. If /etc/veba-release file is missing, DCUI will not load causing blank screen in console

In both cases, DCUI should be able to handle it gracefully as it does not rely on the file to display and we should be able to let user know

Build Action Workflow for VMware Event Router Release Image

Build Action workflow to build and push an image for the VMware Event Router whenever a push to a release* branch is made.

Deployment and vCenter username

When entering the vCenter username during deployment and the vCenter username is a domain user, you must use either of the following two formats:

[email protected]
domain\username (2 backslashes)

If "doman\username" format is entered, the vmware-event-router pod will fail to start.

Backslash must be replaced with \ in JSON

High Availability

Since the appliance is based on k8ts I understand that I could roll my own container platform to provide increased availability, but since this is being packaged as an easy to deploy appliance would it be possible to provide for HA in the product or via documentation?

Thoughts (again, I even hesitate to call myself a k8ts noob, I'm working on it though!)

1. In product?
   a. Deploy appliance as 3 node vApp?
   b. Keep existing single node OVA for simple deployments but provide a second OVA for preconfigured and ready to run additional nodes to create HA cluster.
2. In documentation?
   a. Documentation / howto to build out a k8tes cluster with your appliance OVA and additional nodes, possibly via vanilla PhotonOS OVAs.
   b. Possibly provide scripting to automate the PhotonOS / k8ts setup.

Build Action workflow for PRs against VMware Event Router

Run make build (default Makefile target in vmware-event-router) on every PR opened/further commits to PR and push to development branch.

Update docs on mapping vCenter Events

Update documentation to point customers to https://www.virtuallyghetto.com/2019/12/listing-all-events-for-vcenter-server.html on identifying which vCenter Server Events are available for a given deployment.

AWS EventBridge Processor in VEBA v0.4.0 hangs

It looks like VEBA v0.4.0 hangs when deployed using the AWS EventBridge processor which was reported by a user.

Clarify DNS settings in the OVF

I don't think this code exists in the repo so I can't make a change myself. But I'm happy to do it if somebody points me in the right direction.

When the appliance is packaged, I'm suggesting a simple change to the DNS section. It should read:

DNS Servers (space separated)

If you input comma-separated DNS values, the appliance fails initial configuration because it can't do DNS lookups

Refactor all VEBA components to reference BOM for software download

Avoid Advanced Settings Warning during VEBA Deployment

Update Event Router docs to point to the website

Support multiple events per subscriber

Currently, a function can only subscribe to one event via the topic annotation field.

Support full vCenter event payload and CloudEvents spec

Problem

The current event structure used is rather simple, does not conform to any specification (e.g. CloudEvents) and misses the vCenter event payload (body).

type OutboundEvent struct {
    Topic    string `json:"topic,omitempty"`
    Category string `json:"category,omitempty"`
    Source   string `json:"source"`

    UserName               string                         `json:"userName,omitempty"`
    CreatedTime            time.Time                      `json:"createdTime,omitempty"`
    ObjectName             string                         `json:"objectName,omitempty"`
    ManagedObjectReference *vtypes.ManagedObjectReference `json:"managedObjectReference,omitempty"`
}

Solution Proposal

In order to support richer events a breaking change is required. This issue explores a potential solution using the CloudEvents v1 spec. Following the spec, data would carry the vCenter event payload (encoded as JSON via datacontenttype) as received (i.e. unmodified) from vCenter. type is a combination of com.vmware.vc.event.router and the corresponding event "class", e.g. event (core) or eventex. id is a UUID which can be used for idempotency semantics (detect duplicates) by combining source + id.

Source would map to the vCenter instance which created the event. Subject is the canonical name of the event (CamelCase syntax). time is the event timestamp created by vcenter-connector. data.CreatedTime is the event timestamp created by the corresponding vCenter.

// CloudEvent is the JSON object sent to subscribed functions. We follow
// CloudEvents v1.0 spec as defined in
// https://github.com/cloudevents/sdk-go/blob/6c55828dbb6915e1594e5ace8bd8a19980731867/pkg/cloudevents/eventcontext_v1.go#L22
type CloudEvent struct {
	// ID of the event; must be non-empty and unique within the scope of the producer.
	ID string `json:"id"`
	// Source - URI of the event producer, e.g. http(s)://vcenter.domain.ext/sdk.
	Source string `json:"source"`
	// SpecVersion - The version of the CloudEvents specification the connector implements.
	SpecVersion string `json:"specversion"`
	// Type - canonicalType + vcenter event category (event, eventex, extendedevent).
	Type string `json:"type"`
	// Subject - vcenter event name used for topic subscriptions
	Subject string `json:"subject"`
	// Time - Timestamp set by vcenter connector when this message was created.
	Time time.Time `json:"time"`
	// Data - Event payload as received from vcenter (includes event creation timestamp set by vcenter).
	Data types.BaseEvent `json:"data"`
	// DataContentType - A MIME (RFC2046) string describing the media type of `data`.
	DataContentType string `json:"datacontenttype"`
}

Example event emitted:

{
  "id": "a458f76b-bdf1-4288-b745-2ce89ce37d56",
  "source": "https://10.0.0.101:443/sdk",
  "specversion": "1.0",
  "type": "com.vmware.event.router/event",
  "subject": "VmPoweredOffEvent",
  "time": "2020-01-06T20:49:16.220303Z",
  "data": {
    "Key": 7134,
    "ChainId": 7130,
    "CreatedTime": "2020-01-06T20:48:15.158056Z",
    "UserName": "VSPHERE.LOCAL\\Administrator",
    "Datacenter": {
      "Name": "vcqaDC",
      "Datacenter": {
        "Type": "Datacenter",
        "Value": "datacenter-2"
      }
    },
    "ComputeResource": {
      "Name": "cls",
      "ComputeResource": {
        "Type": "ClusterComputeResource",
        "Value": "domain-c7"
      }
    },
    "Host": {
      "Name": "10.185.16.212",
      "Host": {
        "Type": "HostSystem",
        "Value": "host-21"
      }
    },
    "Vm": {
      "Name": "test-vm",
      "Vm": {
        "Type": "VirtualMachine",
        "Value": "vm-48"
      }
    },
    "Ds": null,
    "Net": null,
    "Dvs": null,
    "FullFormattedMessage": "test-vm on  10.0.0.101 in vcqaDC is powered off",
    "ChangeTag": "",
    "Template": false
  },
  "datacontenttype": "application/json"
}

Benefits

• Reduce round trips to vCenter by providing event payload in the message body
• Support idempotency
• Conform to CloudEvents spec for standardization across different environments

Impact to existing Users

• Breaking change for consumers on the event structure

Support at-least-once delivery semantics

We don't have a good story around at-least-once event delivery (at most once right now). There's different actions we need to take to improve the code to support this, e.g.:

• Checkpointing and replaying vCenter events (if they're still available, downtime may not be > how long vC stores the events), related issue in govmomi
• Retries in Processor.Process
• Queuing, buffering, batching, dealing with throttling and individual batch item failures (when batching)
• Ordered delivery

Document VEBA Software Build-of-Materials (BOM)

This work should also include investigation on how to leverage this BOM file to pull down specific version of the software stack within VEBA, which should aide in making it easier to update in future.

Evaluate using Antrea for networking

https://github.com/vmware-tanzu/antrea

cc/ @yasensim

Document VEBA deployment to existing K8s Cluster

We've had a number of requests from both customers/field on being able to deploy VEBA to an existing K8s Cluster and since VEBA itself is a K8s app, this is something that just needs to be done.

Provide for signed certificates

Can you please allow for signed certificates?

Here are two options I can think of off hand.

1. Provide documentation for changing certificate via kubectl after deployment.
2. Allow for pasting in x509 cer/key pair during deployment of OVA.

Proxy settings do not apply to Docker

Proxy configuration made during OVA deployment is not used for Docker. Issue raised by @sofixa (#32 (comment))

The Docker daemon uses the HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environmental variables in its start-up environment.
Source: https://docs.docker.com/config/daemon/systemd/#httphttps-proxy

Better error handling in the processors

Currently we handle errors coming only from Events coming from vcenter and not the callback functions themselves:

vcenter-event-broker-appliance/vmware-event-router/internal/stream/vcenter.go

Line 88 in 9a9ef34

err := vcenter.stream.Events(ctx, managedTypes, eventsPerPage, tail, force, vcenter.streamCallbackFn(p))

This can be seen in both processors:

• OpenFaaS:
  

  vcenter-event-broker-appliance/vmware-event-router/internal/processor/openfaas.go

  Line 111 in 9a9ef34

  func (openfaas *openfaasProcessor) Process(moref types.ManagedObjectReference, baseEvent []types.BaseEvent) error {

• AWS:
  

  vcenter-event-broker-appliance/vmware-event-router/internal/processor/aws_event_bridge.go

  Line 176 in 9a9ef34

  func (awsEventBridge *awsEventBridgeProcessor) Process(moref types.ManagedObjectReference, baseEvent []types.BaseEvent) error {

We should create custom errors by Implementing the Error method:

type ProcessorErr struct {
    processor string
    content string
}

Implementing the Error interface:

func (e *ProcessorErr) Error() string { return ....}

and the same for OpenFaaS and every processor afterwards. Instead of returning nil return the error in the context of: ProcessorErr.Error("event_bridge","error content").

This will enable better integration testing of the event router.

Honor AWS EventBridge Put Limits

Requires batching (max 10 entries per PutRequest) and rate limiting (per region/account) as described in the limits: https://docs.aws.amazon.com/eventbridge/latest/userguide/cloudwatch-limits-eventbridge.html

Improve linting and validation on Event Router Code

Prioritize eth0 IP Address in vSphere UI

If there are multiple network interfaces (which includes psuedo/logical interfaces like docker0, veth:*, etc) within a GuestOS, VMware Tools will randomly order the addresses which is not ideal if you want to quickly know the primary interface address. This behavior is expected but can be altered by specifying the priority as documented in this blog post here

Below are two different VEBA deployments and you can see in the first deployment, eth0 address is being shown but in the second, the POD Network is actually displayed as the first.

The suggestion and fix is to prioritize eth0 by default in VEBA

Password dictionary check pamlib vs vAPP Password Options Check

Hello VEBA Support,
when installing with the standard vCenter password "VMware1!" an install error occurs.
The password is requested and allowed when entering the vApp options.
However, PAM lib prohibits this password.
Prio: low

Introduce /etc/veba-version

For informational + debugging/troubleshooting purposes, there's no easy way of obtaining the version of VEBA from within the Appliance. Today, the version is only available outside of the VM in the VM Annotation field as well as the filename. If either of those change, then the version is lost and we still do not have a way to identify the release from within.

Proposal is to introduce /etc/veba-version file which would be created on the filesystem and simply contain the version such as v0.4. I'm curious if there's other information we may want to capture @embano1?

Update golangci-lint version used in Dockerfile

Support different event stream providers and processors

Currently only vCenter (source) and OpenFaaS (processors/sinks) are supported. In order to provide more flexibility this should be abstracted (interface) to allow different (and perhaps multiple) sources/processors (sinks).

Change default PID network to prevent collisions

User issue reported:

network 10.32.0.0/12 overlaps with existing route 10.47.159.0/24 on host

Potential workaround: weaveworks/weave#2736 (comment)

PR and test with 10.99.0.0/20 also update limits (number of functions), architecture and FAQ docs on this setting. Make it advanced setting in OVF (end of deployment options setting)?

cc/ @kremerpatrick