Investigate the process of releasing serving-operator in operatorhub

[houshengbo]

Find out the process to release serving-operator in operatorhub, and make it available there in-sync with the knative operator release.

[houshengbo]

We need to have two config maps: config-logging and config-observability, to be created for the serving operator.

How can we bundle or define them in the cluster service version yaml file(metadata)? @jcrossley3

[evankanderson]

Do we need the config maps to exist, or do we want to support configuring them with the operator, but allow them to be empty and use defaults in those cases?

[houshengbo]

@evankanderson This is exactly what I am struggling with. We would like to take advantage of the benefit to call sharedmain.MainWithConfig, but it seems that we have to create ConfigMaps of config-logging and config-observability. We can use the default values, but they have to exist.

[markusthoemmes]

can/should we adjust MainWithConfig to use the default if the configMap cannot be found?

[evankanderson]

It looks like you could probably adjust GetLoggingConfig to handle the "does not exist" case specially; it looks like monitoring doesn't do an initial fetch of the ConfigMap, so maybe only config-logging needs to exist?

https://github.com/knative/pkg/blob/master/injection/sharedmain/main.go#L78

[aliok]

@houshengbo We can close this ticket I think.
We already have the operators in operator hub.
See the comment knative/eventing-operator#70 (comment) and #262

[aliok]

/close

[knative-prow-robot]

@aliok: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.