kedacore / keda-olm-operator

Operator for deploying KEDA Controller on OperatorHub.io/OLM
Apache License 2.0
31 stars 23 forks source link

Refactor KedaController CRD to contain subsections on `operator` and `metricsServer` #130

Closed zroubalik closed 2 years ago

zroubalik commented 2 years ago

Currently the CR looks like this:

apiVersion: keda.sh/v1alpha1
kind: KedaController
metadata:
  name: keda
  namespace: keda
spec:

  ## Namespace that should be watched by KEDA Controller,
  # omit or set empty to watch all namespaces (default setting)
  watchNamespace: ""

  ## Logging level for KEDA Operator
  # allowed values: 'debug', 'info', 'error', or an integer value greater than 0, specified as string
  # default value: info
  logLevel: info

  ## Logging format for KEDA Operator
  # allowed values are json and console
  # default value: console
  logEncoder: console

  ## Logging level for Metrics Server
  # allowed values: "0" for info, "4" for debug, or an integer value greater than 0, specified as string
  # default value: "0"
  logLevelMetrics: "0"

  ## Node selector for pod scheduling - both KEDA Operator and Metrics Server
  # https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/
  nodeSelector:
    beta.kubernetes.io/os: linux

...

It would be better from UX point of veiw to refactor it to contain separate sections for operator and metricsServer, something like this:

apiVersion: keda.sh/v1alpha1
kind: KedaController
metadata:
  name: keda
  namespace: keda
spec:
  ## Namespace that should be watched by KEDA Controller,
  # omit or set empty to watch all namespaces (default setting)
  watchNamespace: ""

  ## KEDA Operator related config:
  operator:
     logLevel: info
     logEncoder: console
     nodeSelector:
       beta.kubernetes.io/os: linux

  ## KEDA Metrics Server related config:
  metricsServer:
     logLevel: "0"
     nodeSelector:
      beta.kubernetes.io/os: linux

...

This way we can add a similar section for serviceAccount or any other resources.

To make the breaking change pleasant for users, temporarily we can support both options, with a warning message printed if a deprecated field is being used.