feature: add custom HTTP client timeout to Metrics API scaler

[RokeshVS]

Adds support for a custom HTTP client timeout to the Metrics API scaler, consistent with the same feature recently added to the Prometheus and Azure Log Analytics scalers in #6607.

Previously, the Metrics API scaler always used the global HTTP timeout configured for KEDA. This change allows users to override that per-trigger via a timeout triggerMetadata field (value in milliseconds).

Changes

• Added timeout field (time.Duration) to metricsAPIScalerMetadata
• Pass meta.timeout to kedautil.CreateHTTPClient in NewMetricsAPIScaler
• Added 3 test cases to testMetricsAPIMetadata covering valid, negative, and non-numeric timeout values
• Updated CHANGELOG.md

Checklist

• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added
• Changelog has been updated and is aligned with our changelog requirements
• A PR is opened to update the documentation on (repo)
• Commits are signed with Developer Certificate of Origin (DCO)

Fixes #7549
Docs: kedacore/keda-docs#1720

[github-actions]

Thank you for your contribution! 🙏

Please understand that we will do our best to review your PR and give you feedback as soon as possible, but please bear with us if it takes a little longer as expected.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Once the initial tests are successful, a KEDA member will ensure that the e2e tests are run. Once the e2e tests have been successfully completed, the PR may be merged at a later date. Please be patient.

Learn more about our contribution guide.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[rickbrouwer]

please run go fmt . on your files for the static check errors.

[RokeshVS]

go fmt .

Done @rickbrouwer

[rickbrouwer]

The scalers were later refactored to comply with the new metadata parsing; see the main branch.

Some adjustments are still needed to comply with that as well, see for example:
https://github.com/kedacore/keda/blob/main/pkg/scalers/azure_log_analytics_scaler.go

[dttung2905]

Hi @RokeshVS ,
thanks for making this PR. Could you help fixing this to make the CI passed

golangci/golangci-lint info checking GitHub for tag 'v2.8.0'
golangci/golangci-lint info found version: 2.8.0 for v2.8.0/linux/amd64
golangci/golangci-lint info installed /home/runner/go/bin/golangci-lint
golangci-lint run
pkg/scalers/metrics_api_scaler.go:101:36: unnecessary conversion (unconvert)
		httpClientTimeout = time.Duration(meta.Timeout) * time.Millisecond
		                                 ^
1 issues:
* unconvert: 1
make: *** [Makefile:163: golangci] Error 1

[RokeshVS]

Hi @RokeshVS , thanks for making this PR. Could you help fixing this to make the CI passed

golangci/golangci-lint info checking GitHub for tag 'v2.8.0'
golangci/golangci-lint info found version: 2.8.0 for v2.8.0/linux/amd64
golangci/golangci-lint info installed /home/runner/go/bin/golangci-lint
golangci-lint run
pkg/scalers/metrics_api_scaler.go:101:36: unnecessary conversion (unconvert)
		httpClientTimeout = time.Duration(meta.Timeout) * time.Millisecond
		                                 ^
1 issues:
* unconvert: 1
make: *** [Makefile:163: golangci] Error 1

Hi @dttung2905 , Thanks for mentioning , Removed unnecessary conversion .

[rickbrouwer]

/run-e2e metric
Update: You can check the progress here

[rickbrouwer]

Thanks for this contribution @RokeshVS !

[JorTurFer]

I know that this is totally consistent with the current scalers, but I'm afraid about supporting the same parameters multiple times. @kedacore/keda-core-contributors @kedacore/keda-core-maintainers, should we support these kind of HTTP options at trigger level and not inside each scaler?

[rickbrouwer]

I know that this is totally consistent with the current scalers, but I'm afraid about supporting the same parameters multiple times. @kedacore/keda-core-contributors @kedacore/keda-core-maintainers, should we support these kind of HTTP options at trigger level and not inside each scaler?

I would like this to discuss on KubeCon and/or the next Community Call.
My brief opinion on this right away: because it is consistent, I would like to let it proceed for now. And after that, a plan to bring it into trigger level for all scalers.

[zroubalik]

I know that this is totally consistent with the current scalers, but I'm afraid about supporting the same parameters multiple times. @kedacore/keda-core-contributors @kedacore/keda-core-maintainers, should we support these kind of HTTP options at trigger level and not inside each scaler?

I would like this to discuss on KubeCon and/or the next Community Call. My brief opinion on this right away: because it is consistent, I would like to let it proceed for now. And after that, a plan to bring it into trigger level for all scalers.

💯

[rickbrouwer]

/run-e2e metric
Update: You can check the progress here

[rickbrouwer]

Let's move on to this PR. Supporting this setting at the trigger level seems like a good candidate for V3 to me, as briefly discussed at KubeCon. Agree @kedacore/keda-core-maintainers ?

[rickbrouwer]

/run-e2e metric
Update: You can check the progress here