List view
Currently, all events from the kfp-operator rely on Argo Events. Consumers need to use Argo Event resources to react to pipeline events, such as a Sensor: https://argoproj.github.io/argo-events/concepts/sensor/. Going forward, the operator should provide a trigger resource that allows a user to abstractly define what should happen on a training event. Users should not need to depend on Argo Events (which has been somewhat unreliable in the past). At a high level, this will involve the creation of two new resources: 1) ClusterTriggerAction - a cluster-wide resource that defines generically what should happen upon an event, such as "serve the model". This could be a native Kubernetes operation i.e. update/patch a ConfigMap. Might be a nice to have - can let the Trigger define the action itself. 2) Trigger - a namespaced-resource that references a ClusterTriggerAction (or just defines the action itself), and connects it with a RunConfiguration, meaning a pipeline event from the Run that the RC triggered can trigger a specific action. Needs to be able to reference a remote RC? Could potentially make use of [KNative Event Mesh](https://knative.dev/docs/eventing/event-mesh/#knative-event-mesh)
No due date