Provider Controller (Step 5)

[grahamia]

Overview

Now that we have simplified our run completion events setup (#359) we can implement a controller to manage Provider custom resources (introduced in #329). The beauty of being down to one component in the provider layer (replacing our Argo Events setup with a single Deployment) is that we have no need to manage multiple resources, so we have no need for helm, and therefore the controller can apply the resource directly.

Technical Details

• Permissions for the Provider controller should be added to the existing roles.yaml, so the temporary manager-providers-viewer-rolebinding ClusterRoleBinding can be removed

Current Architecture

After Architecture

Acceptance Criteria

• When applying a new provider custom resource, the provider service Deployment resource is created
• When updating an existing Provider resource, the provider service Deployment is updated
• When deleting a Provider resource, the provider service Deployment is deleted
• If a provider service Deployment is updated by something other than the Provider controller, the Deployment is re-synced to the desired state specified in the Provider resource
• If a provider service Deployment is deleted by something other than the Provider controller, a new provider service Deployment is created (similarly to how ReplicaSets re-create Pods when deleted)
• The provider service Deployment must have a unique name (similar to how Deployments create pods with unique names)
• The KFP Operator docs have been updated as needed