Service based deny list to throttle state store usage #61
Conversation
…ice (#60) Co-authored-by: Jesse MacFadyen <[email protected]>
TVM will fetch the deny list from denyListUrl if its set Each service impl will have its own deny list processing to provide enough flexibility Deny list will be cached in memory to improve performance. TVM will make sure not to use any deny list beyond its expiry. Changed Cosmos DB token expiration to 10 mins. This will enable to throttle any excessive usage of State Store for a given Namespace
Codecov Report
@@ Coverage Diff @@
## master #61 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 12 12
Lines 345 387 +42
Branches 28 37 +9
=========================================
+ Hits 345 387 +42
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
The logic lgtm but I feel like we are rushing an abstraction over all services to support a denylist and I am not a fan of fetching the denylist file when calling the files or cdn tvm, although they don't implement denylist. Would it be acceptable to move the logic to the cosmos tvm file for now?
If we still want to go for the one fit all solution I would favor having an enable/disable denylist param for every endpoint. And have the processDenyList function be the same for all.
But I might have missed somethings, feel free to debate ;)
| this._validationSchema = { | ||
| /// deployment params - should not be setable by request - deployed as final | ||
| expirationDuration: joi.number().integer().min(900).max(18000).required(), | ||
| expirationDuration: joi.number().integer().min(600).max(18000).required(), |
There was a problem hiding this comment.
Can we change this to be cosmos specific ? I don't remember exactly but maybe 900 was a minimum for aws s3 or azure blob, if not then it's fine
There was a problem hiding this comment.
Let me check this. I don't think 10 mins would hit azure blob minimum, but I will reconfirm this.
There was a problem hiding this comment.
sure also need to check for aws s3
I feel there is no harm to have a generic solution rather than a very specific cosmos related fix. We can easily extend the same design for other services. And each service gets to decide how it processes its own denylist. |
|
lgtm, thanks for the additional details. |
Stopgap fix to throttle State Store DB usage
Description
Related Issue
Motivation and Context
How Has This Been Tested?
Manual Testing against TVM deployment
unit tests
Screenshots (if appropriate):
Types of changes
Checklist: