cc @JorTurFer @zroubalik @CatherineF-dev

This issue is currently awaiting triage.

If custom-metrics-apiserver contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dgrisonnet

The full list of commands accepted by this bot can be found here.

The pull request process is described here

/lgtm

/hold

Feel free to unhold

I tested locally and unit tests passed.

Thanks for the review @CatherineF-dev :)

/unhold

I did an E2E test and found this error. Not sure whether we should do code-gen in custom-metrics-apiserver or not.

F0425 18:59:25.634052       1 openapi.go:43] Failed to build open api spec for root: cannot find model definition for k8s.io/metrics/pkg/apis/custom_metrics/v1beta1.MetricValueList. If you added a new type, you may need to add +k8s:openapi-gen=true to the package or type and run code-gen again

https://github.com/kubernetes/apiserver/blob/master/pkg/server/routes/openapi.go#L43

@CatherineF-dev was that after this specific commit? Or when you tried updating your deps from the old version to the latest? Because it sounds unrelated to that change.

From the look of it, it could be that you are just building the OpenAPI v3 spec instead of building both v2 and v3.

Are you looking at https://github.com/GoogleCloudPlatform/k8s-stackdriver/tree/master/custom-metrics-stackdriver-adapter?

was that after this specific commit? Or when you tried updating your deps from the old version to the latest? Because it sounds unrelated to that change.

Yes, I tried updating deps from the old version to the latest for https://github.com/GoogleCloudPlatform/k8s-stackdriver/tree/master/custom-metrics-stackdriver-adapter.

From the look of it, it could be that you are just building the OpenAPI v3 spec instead of building both v2 and v3.

Thanks for it!

prometheus-adapter is still using sigs.k8s.io/custom-metrics-apiserver v1.27.0.

https://github.com/kubernetes-sigs/prometheus-adapter/blob/master/go.mod#L23

Will upgrade dependencies to sigs.k8s.io/custom-metrics-apiserver v1.27.0 first to see whether the issue is related to custom-metrics-apiserver or not.

I have a bump of prometheus adapter to 1.29.4 locally on which I ran e2e tests and it worked fine.

Is the stackdriver-adapter importing prometheus-adapter ?

E2E test passed in prometheus-adapter kubernetes-sigs/prometheus-adapter#655 after upgrading custom-metrics-apiserver to latest.

Is the stackdriver-adapter importing prometheus-adapter ?

No, stackdriver-adapter depends on custom-metrics-apiserver.

This error F0425 18:59:25.634052 1 openapi.go:43] Failed to build open api spec for root: cannot find model definition for k8s.io/metrics/pkg/apis/custom_metrics/v1beta1.MetricValueList. If you added a new type, you may need to add +k8s:openapi-gen=true to the package or type and run code-gen again is not related to custom-metrics-apiserver.

Time to suggest KEDA as replacement for those adapters? 😉
I'm just kidding, xD I'm going to bump the dep in KEDA too and check if it works. We just use external metrics so maybe the error doesn't happen but as we rely on the default implementation for custom metrics, I guess that all the internal stuff will be compiled too in any case

EDIT: It has worked like a charm and we are already using it

Time to suggest KEDA as replacement for those adapters? 😉

KEDA is an awesome project. I find KEDA provides more functionalities than an adapter. Does KEDA support deploying an adapter only? @JorTurFer

I was kidding when I suggested KEDA 🤣

KEDA is an awesome project. I find KEDA provides more functionalities than an adapter. Does KEDA support deploying an adapter only? @JorTurFer

Do you mean just as the metrics proxy without ScaledObjects and other stuff? No sorry, currently KEDA only supports deploying operator + metrics server, and the scaling configuration has to be provided via CRD (ScaledObject).
This also helps with not requiring complex configurations on adapter side but using more friendly configurations close to workloads (ScaledObjects or ScaledJobs). KEDA just does all the hard work generating the HPA and configuring all the things for the autoscaling :)
The metrics server is just a proxy for Kubernetes, and the admission webhook is an optional component for validating misconfigurations.

Our problem is that the current HPA capabilities are quite limited, despite it's on track with things like scaling to zero supports, currently it's behind a feature gate, so actually it is not supported for almost all the users.

But you can just ping me by slack if you want and I can answer all your questions (or at least I'll do my best answering them xD). I'm Jorge Turrado in Kubernetes and CNCF workspaces