Support YAML format for VMware Event Router Configuration

[embano1]

Is your feature request related to a problem? Please describe. To support templating of the VMware Event Router configuration file, e.g. via Helm, YAML would be the preferred (in case of Helm only) option.

Describe the solution you'd like Instead of JSON use YAML as configuration syntax for the -config of the Event Router.

Describe alternatives you've considered JSON templating solutions, but Helm and others (YTT) have bigger communities.

[embano1]

Here's a first attempt to migrate the current JSON-based configuration format in use to YAML with some additional fields to support versioning, naming of resources, extensibility ([]Provider|Processor) and cleanup for better readability/consistency.

apiVersion: event-router.vmware.com/v1alpha1
kind: RouterConfiguration
metadata:
  labels:
    testkey: testvalue
eventProvider:
  type: vcenter
  name: vcenter01-prod
  vcenter:
    address: https://10.0.0.1:443/sdk
    insecureSSL: false
    auth:
      type: basic
      basicAuth:
        username: admin
        password: VMware1!
eventProcessor:
  type: aws_event_bridge
  name: awseb-us-west
  awsEventBridge:
    region: us-west-1
    eventBus: ABCDEFG123454/awseb/default
    ruleArn: ABCDEFG123454/awseb/rule/1233456
    auth:
      type: aws_access_key
      awsAccessKeyAuth:
        accessKey: ABCDEFGH12345
        secretKey: 263dnbed263enbd
metricsProvider:
  type: internal
  name: default
  internal:
    bindAddress: 0.0.0.0:8081
    auth:
      type: basic
      basicAuth:
        username: root
        password: nimda

@lamw would this work with regards to templatizing the config file (e.g. helm) now?

[lamw]

@embano1 Our existing JSON payload had an options (https://github.com/vmware-samples/vcenter-event-broker-appliance/blob/development/vmware-event-router/deploy/event-router-config-openfaas.json#L12) section that could take in additional configurations WRT to either an event provider or processor? Would this continue to exists?

[embano1]

perhaps not in its general („untyped“) form, but we can add it per provider/processor which is strongly typed and we control which options we expose (see AWS example above). let me update the example to make this more clear. good point!

// updated with additional example (insecureSSL) for vCenter

[lamw]

LGTM 👍

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.