Support fallback of ConfigMap/Secrets in management namespace mode

[haf-tech]

Feature request

Enhance the current management setup with the option of fallback to the default ConfigMap and Secret, in case no dedicated ConfigMap and Secret is defined for a specific namespace.

As-Is

If a management namespace is set (here: safe)

apiVersion: v1
kind: ConfigMap
metadata:
  name: ibmcloud-operator-config
  namespace: openshift-operators # Or update to the namespace where IBM Cloud Operator is running
  labels:
    app.kubernetes.io/name: ibmcloud-operator
data:
  namespace: safe

then the namespace safe should hold the ConfigMap and Secret, e.g.

default-ibmcloud-operator-secret
default-ibmcloud-operator-defaults
test-ibmcloud-operator-secret
test-ibmcloud-operator-defaults
prod-ibmcloud-operator-secret
prod-ibmcloud-operator-defaults

means, for the namespaces default, test and prod are clear ConfigMap and Secret defined. Any ICO Service and Binding CR in those namespaces will use the defined ConfigMap and Secret in safe namespace.

Missing Feature

So, if in this scenario a ICO Service and Binding CR in the not configured namespace demo is created, ICO will cancel the request with the error, that no ConfigMap and Secret found.

To-Be

If a Service and Binding CR in a not configured namespace (here: demo) is created and a config flag enableFallbackToDefault: true is set, then ICO will use the default ConfigMap (here: default-ibmcloud-operator-defaults ) and Secret (here: default-ibmcloud-operator-secret) in the managed namespace (here: safe)

The new configuration field will be expected in the ibmcloud-operator-config ConfigMap

To discuss

How to handle the scenario, if management namespace is enabled, but ConfigMap and Secret are (still) available in the target namespace? E.g.:

$ oc get secret,cm -n safe
default-ibmcloud-operator-secret
default-ibmcloud-operator-defaults
test-ibmcloud-operator-secret
test-ibmcloud-operator-defaults

$ oc get secret,cm -n test
ibmcloud-operator-secret
ibmcloud-operator-defaults

1. Ignore the ConfigMap and Secret in the target namespace (here: test), because user explicitly enabled management namespace?
2. Consider the ConfigMap and Secret in the target namespace (test), but as last (the fallback)
3. Consider the ConfigMap and Secret in the target namespace (test), but first, before the cm/secret in management namespace

I will provide a pull request for this feature, please assign this to me.