Service and ConfigMap specification in ClusterServiceVersion

[sunsingerus]

We are developing operator for ClickHouse and met the following issue(s) with ClusterServiceVersion.

1. Our operator exports Prometheus metrics and we have kind: Service object to provide stable connection point for this. How can kind: Service object be specified in ClusterServiceVersion along with .spec.install.spec.deployments? Or may be there is another approach preferred - like operator creates kind: Service object by itself via k8s API?
2. Our operator has configuration files and some templates provided to it as kind: ConfigMap objects mounted as volumes in operator's Deployment, like:

      volumes:
        - name: etc-clickhouse-operator-folder
          configMap:
            name: etc-clickhouse-operator-files

How these kind: ConfigMaps objects can be specified in ClusterServiceVersion along with .spec.install.spec.deployments and mounted into operator's Deployment? Or may be there is another approach for this?
What would be correct way to bundle operator with additional required objects into ClusterServiceVersion? What to do in case operator requires some configuration files (default and changeable by user) and network services?

Thanks in advance!

[ecordell]

How can kind: Service object be specified in ClusterServiceVersion along with .spec.install.spec.deployments?

We call the CSV + CRDs + extra objects the operator "bundle". Not all types are currently supported, but Service happens to be one that is. That means that if you make an operator bundle like:

 myoperator-1.4.2
 ├── my.crd.yaml
 ├── my.service.yaml
 └── my-operator.clusterserviceversion.yaml

Then when installing via OLM, the service will get created for you.

Or may be there is another approach preferred - like operator creates kind: Service object by itself via k8s API?

This is a good approach if your operator will need to make decisions around the object (other than just ensuring it exists)

Our operator has configuration files and some templates provided to it as kind: ConfigMap objects mounted as volumes in operator's Deployment

Does the operator require the configmap data to start up?

If so, the configmaps could be included in the bundle (like the service). Unfortunately configmaps are not yet supported, unlike Services.

If not, it may make more sense to take advantage of the operator config features. Unfortunately, only env vars are currently supported.

There's not currently a great way to do this, but both of the approaches above should be options in the near future.

[willholley]

Just to add that I also have a requirement for specifying a configmap as part of the CSV. Our operator will (currently) start without it, but we require it to be created and populated before any custom resources are created.

[sunsingerus]

I've made some research on how other operators are being configured.
Unsurprisingly, some of them do use ConfigMap objects.
Surprisingly, these operators simply require these ConfigMap objects to be created (by user, manually, via kubectl) in the same namespace where operator is to be installed, prior to operator installation. Like "create some ConfigMap objects and then install operator". This works, but looks rather clumsy (from my point of view) and seems to be not in the line of desired user experience - to manage everything with OLM.
Are there any best practices or recommendations from experienced OLM users or OLM team regarding configuration?

[sunsingerus]

We call the CSV + CRDs + extra objects the operator "bundle". Not all types are currently supported, but Service happens to be one that is. That means that if you make an operator bundle like:

 myoperator-1.4.2
 ├── my.crd.yaml
 ├── my.service.yaml
 └── my-operator.clusterserviceversion.yaml

operator-courier does not accept bundle like this. It complains on my.service.yaml with

ERROR:operatorcourier.identify:Courier requires valid CSV, CRD, and Package files
Courier requires valid CSV, CRD, and Package files

Still unable to include Service into the bundle.

[sunsingerus]

@ecordell
operator-courier version is 1.2.0, installed with pip

[ecordell]

@sunsingerus courier should allow this now, and if not, would you mind opening the issue against courier? Thanks!

[skonto]

@ecordell what is the rationale behind not supporting this in the CSV spec?