Updated error responses around rate limiting to be more descriptive

[rraavi]

Description

Addressing issue #4798. Minor update.

Related issue and scope

• [ ] I opened an issue to propose and discuss this change (#????)

My changes affect the following components

• [ ] API
• [ ] Controller
• [ ] Message Bus (e.g., Kafka)
• [ ] Loadbalancer
• [ ] Invoker
• [ ] Intrinsic actions (e.g., sequences, conductors)
• [ ] Data stores (e.g., CouchDB)
• [ ] Tests
• [ ] Deployment
• [ ] CLI
• [ ] General tooling
• [ ] Documentation

Types of changes

• [x] Bug fix (generally a non-breaking change which closes an issue).
• [ ] Enhancement or new feature (adds new functionality).
• [ ] Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

• [x] I signed an Apache CLA.
• [x] I reviewed the style guides and followed the recommendations (Travis CI will check :).
• [x] I added tests to cover my changes.
• [ ] My changes require further changes to the documentation.
• [ ] I updated the documentation where necessary.

[rraavi]

Waiting on a stable master, converting PR to draft till then :)

[rraavi]

@dgrove-oss @bdoyle0182 @mrutkows tagging folks for review!

Note: Travis timed out running ./tools/travis/checkAndUploadLogs.sh system command for System Tests job (I couldn't see a way to kick off a new CI build manually)

[mrutkows]

Is there a way to also show the discrete # (perhaps use the same internal config. value the controller uses) to be as descriptive as possible? That is fully address Dave's suggestion in the issue, i.e., "or simply show the total allowed over all the controllers (in this case, 5 controllers (5*240=1200)". I suspect operators would love to be reminded of the configured limits when a user presents them with this error...

[bdoyle0182]

Is there a way to also show the discrete # (perhaps use the same internal config. value the controller uses) to be as descriptive as possible? That is fully address Dave's suggestion in the issue, i.e., "or simply show the total allowed over all the controllers (in this case, 5 controllers (5*240=1200)". I suspect operators would love to be reminded of the configured limits when a user presents them with this error...

I agree I think this is probably the biggest thing we want as to what's misleading. I'm not sure if the current clustering can actually support something like this though or not.

[rraavi]

Is there a way to also show the discrete # (perhaps use the same internal config. value the controller uses) to be as descriptive as possible? That is fully address Dave's suggestion in the issue, i.e., "or simply show the total allowed over all the controllers (in this case, 5 controllers (5*240=1200)". I suspect operators would love to be reminded of the configured limits when a user presents them with this error...

Team, unfortunately this is my first time working with Scala.. I tried to follow along the code but wasn't entirely sure. Are we referring to leverage clusterSize property of LoadBalancer to compute and show the discrete count? I noticed another property named totalActiveActivations.. is this something we can use?

[rabbah]

As noted by @dgrove-oss and @bdoyle0182 each controller lacks total knowledge about the activation counts per namespace. This message will even vary per controller depending on which services the request. So the "currently running" count is for the specific controller that was assigned the activation.

[rraavi]

So, close the linked PR right?

[style95]

I have little idea about the history of this PR. Is this ready to merge?