Improve context propagation to Scalers

[jerbob92]

Proposal

At this point, the scalers only receive a context in the scaler methods GetMetrics() and IsActive().

I think there are 2 issues that we face right now:

1. A lot of Scalers don't actually use the available context, while a lot of them just do HTTP requests which can use context just fine (just use http.NewRequestWithContext() instead of http.NewRequest()).
2. There is no context available in buildScaler, while some Scalers would be able to use a context there (the Redis Scaler pings the Redis server in the buildScaler logic)

The first issue is quite easy to fix, every Scaler should be checked whether it can use a context in GetMetrics() or IsActive() and then implement that. If it already uses it we should check if it uses it properly. (for example, MongoDB scaler does use a context in the CountDocuments() method, but it extends context.Background() instead of the given context in GetMetrics() and IsActive()).

The second issue is harder. If you look at the code in scale_handler.go, if you go back far enough from buildScaler, you eventually find a context in startPushScalers and startScaleLoop. This is the cancelable context from HandleScalableObject. The question would be if that is the right context to pass to the buildScaler, or whether we have to introduce a new cancelable context.

Use-Case

A context is a useful feature of Go to pass arbitrary values around, but it also provides features like canceling and timeouts. A lot of libraries allow you to pass a context to it when doing stuff, for example:

• http.NewRequestWithContext()
• redis-go, in all it's commands
• PostgreSQL/MySQL/MSSQL Scaler (due to SQL's QueryRowContext)
• MongoDB
• Probably more that I didn't see

If we would use context's properly everywhere, Scalers have to spend less time on tasks that would otherwise timeout/cancel.

Anything else?

Anything to add @zroubalik?

[zroubalik]

@jerbob92 thanks for opening this, well written.

[zroubalik]

@ahmelsayed do you think that you can prepare the code in #2187 so we can later resolve the second issue mentioned here.

[arschles]

@jerbob92 @zroubalik I can take on the first point in the original post. Is that ok?

[zroubalik]

@arschles that would be great!

[arschles]

work started in #2202

[arschles]

Now that #2187 is merged, I can take (2). I'll submit a draft PR today to start it.