Support Seldon Core v1 in Operator Framework Community Operator

[ukclivecox]

Our Operator is built using Kubebuilder v2 which is presently incompatible with Operator Lifecycle Manager needed for Operator Framework Community Operators

• Configmaps are not supported by CSV
• Webhook configuration not supported by CSV
• Need to support WATCH_NAMESPACE

[ryandawsonuk]

Related #1482

[dmesser]

For the benefit of the curious reader:

• Configmaps are not supported by CSV

This is true as of today. OLM will support bundles in the future that allow you to ship any Kubernetes manifest, including ConfigMaps. In the meantime alternatives are to have that ConfigMap be lifecycled by your Operator (create on startup) and populate it with the defaults you are encouraging.

• Webhook configuration not supported by CSV

This is also true as of today. In the next 3 months we are looking to release support to reference mutating and admission webhooks in your CSV. OLM would then lifecycle them as first-class objects, including configuration for cert-rotation.

• Need to support WATCH_NAMESPACE

This should be fairly easy to achieve since it's actually natively supported by controller-runtime.

[tmckayus]

@cliveseldon if I understand correctly what you're wanting to do, one potential approach to the configmap limitation is to mount a known configmap as an optional volume in the deployment listed in the CSV. The operator image can either store defaults, or if no sane defaults are viable it can loop with a message "create config map x and restart the operator pod". Subsequently, if a user creates the configmap and kills the operator pod, the operator will restart and mount the configmap volume.

Additionally, if the name of the configmap needs to be flexible, it can be defaulted and then overridden by an env var added to the subscription object when the operator is installed.

Does this sound like a viable workaround?

[ukclivecox]

@tmckayus I think creating the configmap if it does not exist on operator startup is best solution RBAC permitting.

@dmesser If we also create the webhooks in the operator how can be ensure certs are correctly applied?

Under the vanilla installation we assume either a) cert-manager is available and we can create the cert-manager resources to get them injected or b) we create a self-signed cert for non-production use case or 3) the user can update the Kustomize/helm to add their own cert. None of these sound like the openshift way thus the question if we try to do this work before webhooks are handled by OLM natively.

[dmesser]

@cliveseldon OpenShift has it's own cert rotation Operator, so that would be an option but asks for an OpenShift-specific version of your Operator for the time being. We are aiming to release support for cert rotation on webhooks in June this year.

[ukclivecox]

@dmesser Thanks. Any links to the docs if I want to create a webhook configuration from operator and get certs correctly figured and setup in a manner that community-operators would accept?

[ukclivecox]

Further info from operator-sdk : operator-framework/operator-sdk#1217