knative events implementation

[lkingland]

The knative adapter implementation is currently a stub. It should be fleshed out to include a full knative client instance which implements simple event subscription and registration. This is essentially implementing the simplest possible use case of an eventing system: pub/sub using an arbitrary event name.

For example, the following are implementation examples using local .yaml files from the POC by @lance which show this use case implemented using local config files:

apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
  name: monitor-cron
spec:
  broker: default
  filter:
    attributes:
      type: function-response
      source: monitor-boson--project-ort
    subscriber:
      ref:
        apiVersion: v1
        kind: Service
        name: api-boson--project-org

apiVersion: source.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
  name: job-a
spec:
  schedule: "*/1 * * * *"
  data: '{"job": "a", "status", "OK"}'
  sink:
    ref:
      apiVersion: eventing.knative.dev/v1alpha1
      kind: Broker
      name: Default

apiVersion: source.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
  name: job-b
spec:
  schedule: "*/1 * * * *"
  data: '{"job": "b", "status", "OK"}'
  sink:
    ref:
      apiVersion: eventing.knative.dev/v1alpha1
      kind: Broker
      name: Default

apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
  name: monitor-cron
spec:
  broker: default
  filter:
    attributes:
      type: dev.knative.cronjob.event
    subscriber:
      ref:
        apiVersion: v1
        kind: Service
        name: monitor-boson--project-org

It is entirely possible that in the process of implementing this use case, the shape of the Adapter interface will need to change. We should probably default to a shape that jives most closely with the Knative API, as we will soon be adding more advanced use cases, so the closer we stick to that API now the easier our job will be in the future. Furthermore, if we can settle on a good base case now, we will be less likely to have to make changes to the implementation for other platforms such as the Brasilia adapter implementation.

One caviat here is that the implementation will need to run from within a deployed knative service, not from the client, so authentication will be based on the permissions granted the pod at runtime.