kedacore / keda-olm-operator Goto Github PK

Release 2.10.2 to incorporate changes in OLM operator that has been introduced after 2.10.1 but are still relevant to this release. The operator should work on plain k8s as well (certs rotation).

According to https://github.com/kedacore/keda-olm-operator/blob/main/RELEASE-PROCESS.md#8-create-keda-release-on-github Git should automatically build images based upon the release and push them to DockerHub. It appears that this is not working as DockerHub doesn't show any releases after 2.5.0:

https://hub.docker.com/r/kedacore/keda-olm-operator/tags

Expected Behavior

New releases should appear on DockerHub

Actual Behavior

New releases do not appear on DockerHub

Steps to Reproduce the Problem

1. Look at current releases: https://github.com/kedacore/keda-olm-operator/releases
2. Look at DockerHub tags: https://hub.docker.com/r/kedacore/keda-olm-operator/tags
3. Notice that newer releases do not have a corresponding tag on DockerHub.

Specifications

• KEDA OLM Operator Version: 2.10.1
• KEDA Version: Please elaborate: 2.10.1
• Platform & Version: Please elaborate: linux/amd64
• Kubernetes Version: Please elaborate: Any
• OLM Version: Please elaborate: Any

On OpenShift 4.6 and higher, the operand (KedaController CR in our case) could be automatically installed when installing keda-olm-operator through OLM.

We should use this
http://openshift.github.io/openshift-origin-design/designs/administrator/olm/operand-creation-at-operator-install/

tl;dr: KEDA 2.5.0 will have options to configure audit logs for its metrics server, so it would be great to make them customizable by the OCP users

The KedaController custom resource currently only allows configuring Keda's log level, which will not be very helpful when trying to understand where an autoscaling request is coming from. This is key information when backends are getting overloaded by autoscaling requests made by user applications and we are trying to figure out who is the rogue application. To make that possible the custom-metrics-apiserver library added the capacity to configure audit logs to the generic apiserver that is serving the Kubernetes metrics API. This feature is only available starting from v1.22 of the library which is what KEDA's main branch is using, but it isn't in any official release of the project yet. Once a new official release is cut and brought downstream, I think we should make it possible for the users to enable audit logs since this information can be extremely valuable for debugging purposes.

Use-Case

An openshift customer opens a Bugzilla saying that Prometheus has a constant 100% CPU usage. After investigating we know that the application making the most consuming requests to Prometheus is KEDA. However, we don't know which application is making the requests to KEDA. With audit logs, we could track down where the autoscaling request is coming from and identify the rogue application that is behind the requests.

A similar effort is in progress to have audit logs for the resource metrics API: https://issues.redhat.com/browse/MON-1786

It would be great to have a detailed example for using EventHub scaler

Use-Case

Tell us more what you'd like to achieve

Specification

• Demand #1

Add 'replaces: keda.v2.0.0' into CSVs when new version of keda olm operator will be deployed.

Run tests from #19 periodically and for each PR

When installing the keda operator I am seeing a large number of TLS handshake error on the admission pod. Currently around 175k log entries in 24 hours.

2023/11/16 16:30:15 http: TLS handshake error from 100.68.1.30:34016: remote error: tls: bad certificate
2023/11/16 16:30:16 http: TLS handshake error from 100.68.1.30:34026: remote error: tls: bad certificate
2023/11/16 16:30:18 http: TLS handshake error from 100.68.1.30:49564: remote error: tls: bad certificate
2023/11/16 16:30:18 http: TLS handshake error from 100.68.1.30:49580: remote error: tls: bad certificate
2023/11/16 16:30:19 http: TLS handshake error from 100.68.1.30:49592: remote error: tls: bad certificate
2023/11/16 16:30:21 http: TLS handshake error from 100.68.1.30:49598: remote error: tls: bad certificate
2023/11/16 16:30:21 http: TLS handshake error from 100.68.1.30:49612: remote error: tls: bad certificate
2023/11/16 16:30:22 http: TLS handshake error from 100.68.1.30:49622: remote error: tls: bad certificate

In the operator controller pod we're also getting spammed with logs like;

2023-11-16T16:32:52Z ERROR cert-rotation Error updating webhook with certificate {"name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration", "error": "Operation cannot be fulfilled on validatingwebhookconfigurations.admissionregistration.k8s.io \"keda-admission\": the object has been modified; please apply your changes to the latest version and try again"}
github.com/open-policy-agent/cert-controller/pkg/rotator.(*ReconcileWH).ensureCerts
/workspace/vendor/github.com/open-policy-agent/cert-controller/pkg/rotator/rotator.go:752
github.com/open-policy-agent/cert-controller/pkg/rotator.(*ReconcileWH).Reconcile
/workspace/vendor/github.com/open-policy-agent/cert-controller/pkg/rotator/rotator.go:702
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile
/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:118
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:314
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:265
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:226
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService", "name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService"}
2023-11-16T16:32:52Z ERROR Reconciler error {"controller": "cert-rotator", "object": {"name":"kedaorg-certs","namespace":"kube-keda"}, "namespace": "kube-keda", "name": "kedaorg-certs", "reconcileID": "5e6b9054-5ab9-4932-ab3a-98b8b7a1c3d8", "error": "Operation cannot be fulfilled on validatingwebhookconfigurations.admissionregistration.k8s.io \"keda-admission\": the object has been modified; please apply your changes to the latest version and try again"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:324
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:265
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:226
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration", "name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration"}
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService", "name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService"}
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration", "name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration"}
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService", "name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService"}
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration", "name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration"}
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService", "name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService"}
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration", "name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration"}
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService", "name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService"}
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration", "name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration"}
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService", "name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService"}
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration", "name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration"}
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService", "name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService"}
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration", "name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration"}
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService", "name": "v1beta1.external.metrics.k8s.io", "gvk": "apiregistration.k8s.io/v1, Kind=APIService"}
2023-11-16T16:32:52Z INFO cert-rotation Ensuring CA cert {"name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration", "name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration"}
2023-11-16T16:32:52Z ERROR cert-rotation Error updating webhook with certificate {"name": "keda-admission", "gvk": "admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration", "error": "Operation cannot be fulfilled on validatingwebhookconfigurations.admissionregistration.k8s.io \"keda-admission\": the object has been modified; please apply your changes to the latest version and try again"}
github.com/open-policy-agent/cert-controller/pkg/rotator.(*ReconcileWH).ensureCerts
/workspace/vendor/github.com/open-policy-agent/cert-controller/pkg/rotator/rotator.go:752
github.com/open-policy-agent/cert-controller/pkg/rotator.(*ReconcileWH).Reconcile
/workspace/vendor/github.com/open-policy-agent/cert-controller/pkg/rotator/rotator.go:702
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile
/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:118
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:314
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:265
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:226

Steps to Reproduce the Problem

1. Install Keda OLM via OperatorHub
2. Create a KubeController
3. Check logs on keda operator and admission pods.

Specifications

• KEDKEDA OLM Operator VersionA OLM Operator Version
• KEDA Version: 2.11.2
• Platform & Version: OKD 4.12.0-0.okd-2023-04-01-051724
• Kubernetes Version: 1.25

When creating ScaledObject from the OCP Console, it is not possible to specify trigger-specific fields such as the serverAddress and the metricName for the Prometheus scaler. As such, it is not possible to create a valid ScaledObject from the Console without having to modify the resource afterward.

Expected Behavior

I would have expected to be able to configure a valid Prometheus trigger from the OCP Console.

Actual Behavior

These were the only fields I was able to configure:

From a UX perspective, I would've expected the type field to be a drop-down list where I could have chosen the type I wanted to use, and then it would have displayed the scaler-specific fields for me to configure.

Steps to Reproduce the Problem

1. Install Keda via OLM
2. Create ScaledObject from the Console

Specifications

• KEDA OLM Operator Version: latest
• KEDA Version: 2.4.0
• Platform & Version: 4.10
• Kubernetes Version: 1.22
• OLM Version:

Set up test infra (k8s cluster) that can be used to run tests.

https://github.com/marketplace/actions/kind-kubernetes-in-docker-action

After the recent update and changes the nightly tests start failing:

https://github.com/kedacore/keda-olm-operator/actions/runs/5300826565

There are clear instructions for how to enable and use AAD pod identity when installing KEDA with the Helm chart, but there don't seem to be any instructions for how to do so with the OLM operator. Is it possible? If not, it would be extremely useful to add that capability.

Report

we have installed KEDA through the operator in one of our environments, as soon as it gets installed it crashes with OOMKilled error

Expected Behavior

Should be up and running

Actual Behavior

OOMKilled

Steps to Reproduce the Problem

1. Install through KEDA operator

Logs from KEDA operator

"level":"info","ts":1627725081.8786712,"logger":"setup","msg":"Go OS/Arch: linux/amd64"}
{"level":"info","ts":1627725081.8789783,"logger":"controller-runtime.manager","msg":"starting metrics server","path":"/metrics"}
{"level":"info","ts":1627725081.8790333,"logger":"controller","msg":"Starting EventSource","reconcilerGroup":"","reconcilerKind":"Secret","controller":"secret","source":"kind source: /, Kind="}
{"level":"info","ts":1627725081.8790953,"logger":"controller","msg":"Starting EventSource","reconcilerGroup":"","reconcilerKind":"ConfigMap","controller":"configmap","source":"kind source: /, Kind="}
{"level":"info","ts":1627725081.8791132,"logger":"controller","msg":"Starting EventSource","reconcilerGroup":"keda.sh","reconcilerKind":"KedaController","controller":"kedacontroller","source":"kind source: /, Kind="}
{"level":"info","ts":1627725081.9794464,"logger":"controller","msg":"Starting EventSource","reconcilerGroup":"keda.sh","reconcilerKind":"KedaController","controller":"kedacontroller","source":"kind source: /, Kind="}
{"level":"info","ts":1627725082.1797862,"logger":"controller","msg":"Starting Controller","reconcilerGroup":"keda.sh","reconcilerKind":"KedaController","controller":"kedacontroller"}
{"level":"info","ts":1627725083.8492484,"logger":"controller","msg":"Starting [Controller","reconcilerGroup":"","reconcilerKind":"ConfigMap","controller":"configmap"}](url)

KEDA Version

2.3.0

Kubernetes Version

1.18

Platform

Red Hat OpenShift

Scaler Details

No response

Anything else?

No response

Expected Behavior

Keda's external metrics apiservice endpoint should continue to work on a long-running OpenShift cluster.

Actual Behavior

Keda's external metrics apiservice endpoint stops working as soon as OpenShift rotates certificates.

Steps to Reproduce the Problem

1. Install the KEDA operator
2. oc get apiservice v1beta1.external.metrics.k8s.io and verify Available is True.
3. Wait for OpenShift to rotate certificates - 24 hours after creation of a brand new cluster, periodically after that
4. oc get apiservice v1beta1.external.metrics.k8s.io and see Available is now False.

Specifications

• KEDA OLM Operator Version 1.3.0
• KEDA Version: (whatever's installed by 1.3.0 operator)
• Platform & Version: Openshift Container Platform 4.3.8
• Kubernetes Version: 1.16
• OLM Version: OCP 4.3.8

At the moment the resources file is being loaded into the operator during the startup:

It would be better to use go embed feature introduced in Go 1.16: https://golangtutorial.dev/tips/embed-files-in-go/

• LeaderElectionID: "olm.keda.sh"
  

  keda-olm-operator/main.go

  Line 77 in e2d8ac2

  LeaderElectionID: "b670c7de.sh",

• remove bin directory
• in boilerplate.go.txt use content from kedacore/keda
  https://github.com/kedacore/keda-olm-operator/blob/master/hack/boilerplate.go.txt
  ->
  https://github.com/kedacore/keda/blob/v2/hack/boilerplate.go.txt
• fix markers to comply with contents in rbac.yaml (and regenerate)
  

  keda-olm-operator/controllers/kedacontroller_controller.go

  Lines 75 to 79 in e2d8ac2

  	// +kubebuilder:rbac:groups=keda.sh,resources=kedacontrollers,verbs=get;list;watch;create;update;patch;delete
  	// // +kubebuilder:rbac:groups=keda.sh,resources=kedacontrollers/status,verbs=get;update;patch
  	// +kubebuilder:rbac:groups=keda.sh,resources=kedacontrollers;kedacontrollers/finalizers;kedacontrollers/status,verbs="*"
  	// +kubebuilder:rbac:groups="*",resources="*/scale",verbs="*"
  	// +kubebuilder:rbac:groups="*",resources="*",verbs=get

• configmap and secret controllers are missing in controllers, original location: https://github.com/kedacore/keda-olm-operator/tree/a4d99c811486527aa917b1286d0cd130eb5cdf1d/pkg/controller

Makefile:

• replace$IMG

  keda-olm-operator/Makefile

  Line 66 in e2d8ac2

  cd config/manager && $(KUSTOMIZE) edit set image controller=${IMG}

• remove this:

  keda-olm-operator/Makefile

  Lines 17 to 20 in e2d8ac2

  	# Image URL to use all building/pushing image targets
  	IMG ?= controller:latest
  	# Produce CRDs that work back to Kubernetes 1.11 (no version conversion)
  	CRD_OPTIONS ?= "crd:trivialVersions=true"

• replace $(CONTROLLER_GEN) $(CRD_OPTIONS) with $(CONTROLLER_GEN) crd:crdVersions=v1

  keda-olm-operator/Makefile

  Line 90 in e2d8ac2

  $(CONTROLLER_GEN) $(CRD_OPTIONS) rbac:roleName=manager-role webhook paths="./..." output:crd:artifacts:config=config/crd/bases

Use-Case

https://github.com/kedacore/keda-olm-operator/blob/main/RELEASE-PROCESS.md

Specification

• #213
• #215

Use-Case

I would like to use KEDA OLM Operator to deploy multiple KEDA controllers, each one monitoring one specific namespace.
However, when I tried it, it seems that it got ignored with the following error message in the OLM container logs:

The KedaController resource needs to be created in namespace keda with name keda, otherwise it will be ignored

Specification

It seems that KEDA itself allows deployment in namespaces other than keda.

• Please remove the constraint if technically possible in order to allow having multiple KEDA controllers deployed in the same cluster.

A clear and concise description of what you want to happen.

I am using Fluentd to send logs to ELK and multiline KEDA logs are not handled properly.

Use-Case

Obviously, it is possible to create a regex definition to handle multiline logs but
the ideal option will be if KEDA logs will be in Json format to make it easier to work with.

Specification

To be more specific - here is the example - by default call stack details are processed as single-line log entries

2021-03-27T11:24:07.220Z ERROR controller Reconciler error {"reconcilerGroup": "keda.sh", "reconcilerKind": "ScaledObject", "controller": "scaledobject", "name": "function-eventhub-processing", "namespace": "default", "error": "Operation cannot be fulfilled on scaledobjects.keda.sh "function-eventhub-processing": StorageError: invalid object, Code: 4, Key: /registry/keda.sh/scaledobjects/default/function-eventhub-processing, ResourceVersion: 0, AdditionalErrorMsg: Precondition failed: UID in precondition: fb1508ea-aa4d-4cfb-90c5-5acf5b383beb, UID in object meta: "}

github.com/go-logr/zapr.(*zapLogger).Error /go/pkg/mod/github.com/go-logr/[email protected]/zapr.go:128 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler /go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:237 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem /go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:209 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).worker /go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:188 k8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1 /go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:155 k8s.io/apimachinery/pkg/util/wait.BackoffUntil /go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:156 k8s.io/apimachinery/pkg/util/wait.JitterUntil /go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:133 k8s.io/apimachinery/pkg/util/wait.Until /go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:90

• Demand #1

A clear and concise description of what the bug is.

Expected Behavior

requests should be less or equal than limits in KedaConroller example.

Actual Behavior

requests are more that limits

  ## Manage resource requests & limits for KEDA Operator
  # https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
  # resourcesKedaOperator:
  #   limits:
  #     cpu: 100m
  #     memory: 100Mi
  #   requests:
  #     cpu: 1000m
  #     memory: 1000Mi

  ## Manage resource requests & limits for KEDA Metrics Server
  # https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
  # resourcesMetricsServer:
  #   limits:
  #     cpu: 100m
  #     memory: 100Mi
  #   requests:
  #     cpu: 1000m
  #     memory: 1000Mi

Steps to Reproduce the Problem

1. use example resource definition
2. keda contoller installation failed

Specifications

• KEDA OLM Operator Version 2.4.0
• KEDA Version: 2.4.0
• Platform & Version: Openshft 4.7
• Kubernetes Version: any
• OLM Version: any

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.

A clear and concise description of what the bug is.

Expected Behavior

Actual Behavior

Steps to Reproduce the Problem

Specifications

• KEDA OLM Operator Version
• KEDA Version: Please elaborate
• Platform & Version: Please elaborate
• Kubernetes Version: Please elaborate
• OLM Version: Please elaborate

• test operator functionality
• test OLM functionality - implement e2e tests

Update deps & update operator-sdk verison

We should run a build for each commit and automatically push to Docker Hub, same way it is done for KEDA: https://github.com/kedacore/keda/tree/master/.github

Add logFormat option to KedaController, so users can specify preferred log format. See related change in KEDA:
https://github.com/kedacore/keda#keda-operator-logging
https://github.com/kedacore/charts/pull/41/files
kedacore/keda#766

This isn't a feature request but neither is an actual bug report, at least not with the operator itself.

Currently observing that Openshift instances on IBM Cloud and on AWS are pretty much stuck with KEDA v2.7.1, if operator is installed from the Hub.
On a different cluster (on-prem) we deployed KEDA using helm, it's running KEDA 2.12.1 as expected.
Perhaps some note is needed in the readme to raise awareness that Hub installation can be problematic. Message on Hub does say (Depricated) but it was working just fine until the semi-recent kubernetes upgrade on the openshift.

With a manual install one needs to be aware that KEDA version have to be matched with a proper kubernetes versions, to avoid this:

xxxxx INFO setup Running on Kubernetes 1.25 {"version": "v1.25.16+a4e782e"}
xxxxx INFO setup WARNING: KEDA 2.12.1 hasn't been tested on Kubernetes v1.25.16+a4e782e

Found the link to the mapping:
https://keda.sh/docs/2.13/operate/cluster/

edit: we used helm for the on-prem deployment, not the operator

A clear and concise description of what the bug is.

Expected Behavior

Actual Behavior

Steps to Reproduce the Problem

Specifications

• KEDA OLM Operator Version
• KEDA Version: Please elaborate
• Platform & Version: Please elaborate
• Kubernetes Version: Please elaborate
• OLM Version: Please elaborate

Hi,

we want to use Keda and have noticed that in OKD over the operator HUB it has been marked depricated 😞

2.7.1 provided by KEDA Community is also a little out of date. Are there any plans to update to current Release?

We do not want to use the redhat auto Scaler operator.

Regards Philipp

There are new configuraiton options in KEDA Helm Charts and to KEDA in general that haven't been added to KedaController.

https://github.com/kedacore/charts/tree/main/keda#configuration

We should identify missing options and try to add as much as possible to this operator, preferrably for the upcoming 2.13 release:, KEDA 2.13 has been released today: https://github.com/kedacore/keda/releases/tag/v2.13.0

Some things from the top of my head:

• certificates and CA management
• possiblilty to specify arbitrary arguments to binaries both in all containers
• possibility to disable validation webhooks
• clusterDomain
• ...

Add markers so that CSVs are generated correctly.

logTimeFormat was removed but zap-encoder was added: https://github.com/kedacore/keda/blob/main/BUILD.md#keda-operator-logging

We should modify the KedaController resource, the property for zap-encoder should be probably named logEncoder

Don't forget to update Readme and samples in config/samples
https://github.com/kedacore/keda-olm-operator#kedacontroller-spec

Use-Case

https://github.com/kedacore/keda-olm-operator/blob/main/RELEASE-PROCESS.md

Implement validating webook that check that new KedaController CustomResource is created in correct namespace (eg. keda).

https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/

operator-framework/community-operators#1680

spec.loglevel, spec.loglevelMetrics and other global fields are deprecated, fields under spec.operator and spec.metricsServer should be use instead.

New flelds on KedaController resource, that will allow users to specify arbitrary args for both Operator & Metrics Server deployments. No need for validation. This args can replace any existing or previously defined args.

Use-Case

Allow users to specify any args on both deployments via KedaController resource.

Change manifestival repo reference and update neccessary functions to comply with the latest version.

Move from github.com/jcrossley3/manifestival -> github.com/manifestival/manifestival