autoscaling

The resource name and the queue endpoint suffix should be configurable in triggers.

https://github.com/kedacore/keda/blob/57ffd4ee384db38f1169453cb16b31f00eacffa5/pkg/scalers/azure/azure_storage.go#L34-L64

Task List

• #1921
• #1916
• #1915
• #1917
• #1918
• #1920
• #1919

Is your feature request related to a problem? Please describe.

Updating escalator config currently requires a pod restart. We should update escalator to automatically read new config upon changing on disk.

Describe the solution you'd like

Check for changes in nodegroup config before each run. If safe to do so, run with the new config.

*Describe alternatives you've considered

Description

With the changes introduced in #227, Noma API calls for job scaling operations were updated to permit stale reads. We should update the remainder of Nomad API calls for consistency and decreased load on the Nomad Servers.

We have often see developer telling us the problems going on with WPA and then the first way to debug the issue is by going through WPA kubernetes logs for the queue to find what is going on. We should logs events for all the important thing that goes on with the WPA object.

Reasons:

1. Easy to debug.
2. Developer who does have access to wpa logs but has access to their WPA object can tro

There are quite a few places where we have to consume a kubernetes resource, watch it for changes, and keep a copy of it (or some data derived from a copy of it) in memory and up-to-date. So far, we have written code from scratch that uses a watch.Interface to watch for changes, and uses a Kubernetes client to periodically do a full fetch of the Kubernetes resource(s) in question.

In #269, we

The port limit constant (10) should be lifted into a constant and reused in our ports value validation, in the k8s get-port-range function, and anywhere else it is used.

See twosigma/waiter#1193 (comment)