Support HTTPScaledObject scoped timeout

[JorTurFer]

Proposal

Currently, there is a timeout configuration for setting the request timeout.
Allowing HTTPScaledObjects to override the timeout for specific route can help to users who have some slow routes but they prefer to not increase the global timeout for all the routes just due to some of them

Use-Case

No response

Is this a feature you are interested in implementing yourself?

Maybe

Anything else?

No response

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed due to inactivity.

[oto-macenauer-absa]

Hi, is this expected in future releases?

We're using shared k8s cluster so it would be easier to use scoped timeout than asking platform team to come with values that fit all teams sharing the cluster. Also what kinds of timeouts is this expected to support?

[JorTurFer]

Hi, is this expected in future releases?

No, this has been closed automatically due to inactivity. Are you willing to contribute with it?

We're using shared k8s cluster so it would be easier to use scoped timeout than asking platform team to come with values that fit all teams sharing the cluster. Also what kinds of timeouts is this expected to support?

The original proposal was to override the "cold start timeout"

[oto-macenauer-absa]

No, this has been closed automatically due to inactivity. Are you willing to contribute with it?

Sorry, I don't have any experience with go and this doesn't seem like easy task to start.

The original proposal was to override the "cold start timeout"

Ok, we got API that can take long to answer so I was looking for something to override the responseHeaderTimeout

[JorTurFer]

I've checked and I guess that we could configure all the timeouts at same place from the HTTPScaledObject, so maybe could support all of them.
https://github.com/kedacore/http-add-on/blob/main/interceptor/proxy_handlers.go#L46-L86

@tomkerkhove ?

[tpfau]

Having something like this would be great. We were trying to deploy LLMs this way on a cluster, having at most a few requests pending before adding new resources.
But the responses (at least non streamed ones) can take quite some time before they are ready and those are then killed by the 500ms response header timeout and updating this for individual endpoints/pods would be great.