-
Notifications
You must be signed in to change notification settings - Fork 53
feat: add ability to configure tes error cache expire time #1751
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Binary incompatibility detected for commit 732599d. com.aws.greengrass.tes.CredentialRequestHandler is binary incompatible and is source incompatible because of FIELD_REMOVED Produced by binaryCompatability.py |
|
Unit Tests Coverage Report
Minimum allowed coverage is Generated by 🐒 cobertura-action against 732599d |
|
Integration Tests Coverage Report
Minimum allowed coverage is Generated by 🐒 cobertura-action against 732599d |
|
|
||
| public static final String CLOUD_4XX_ERROR_CACHE_TOPIC = "cloud4xxErrorCacheInSec"; | ||
| public static final String CLOUD_5XX_ERROR_CACHE_TOPIC = "cloud5xxErrorCacheInSec"; | ||
| public static final String UNKNOWN_ERROR_CACHE_TOPIC = "unknownErrorCacheInSec"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Move these to TES class file and rename them to reflect the configuration topics.
The configuration topic names are too implementation specific. These expiration times are when TES will retry fetching credentials again, right? Can we instead call them as error4xxCredentialRetryInSec?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved them to TES class and renamed them
| this.credentialRequestHandler = credentialRequestHandler; | ||
|
|
||
| cloud4xxErrorCache = validateCacheConfig(Coerce.toInt(config.lookup( | ||
| CONFIGURATION_CONFIG_KEY, CLOUD_4XX_ERROR_CACHE_TOPIC).dflt( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's replace this with findOrDefault?
lookup and dflt create configuration nodes (topics). We don't always need to write the default values to config file for optimization reasons (such as having less no of writes and callback events, and config file remains smaller without losing information).
| logger.atDebug("tes-cache-config-change").kv("node", node).kv("why", why).log(); | ||
|
|
||
| int newCloud4xxErrorCache = validateCacheConfig(Coerce.toInt(config.lookup( | ||
| CONFIGURATION_CONFIG_KEY, CLOUD_4XX_ERROR_CACHE_TOPIC).dflt( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as above to not use dflt as this will trigger the subscribe callback again with the updated value when the node value is null.
| private int validateCacheConfig(int newCacheValue, int oldCacheValue) { | ||
| if (newCacheValue < MINIMUM_ERROR_CACHE_IN_SEC) { | ||
| logger.atError().log("Error cache value must be at least {}", MINIMUM_ERROR_CACHE_IN_SEC); | ||
| return oldCacheValue; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of the old value, we'd want to use default value for each of these or the minimum error cache value. We don't know if the old value itself is valid or not.
| credentialRequestHandler.configureCacheSettings(cloud4xxErrorCache, cloud5xxErrorCache, unknownErrorCache); | ||
|
|
||
| // Subscribe to cache configuration changes | ||
| config.subscribe((why, node) -> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be combined with the existing subscribe callback for port changes as it will otherwise create two callback executions when port and error cache config are updated at the same time .
If both port and error cache config are updated at the same time, it is enough to restart TES once.
… avoid multiple restarts
7b3fd9b to
732599d
Compare
Issue #, if available:
Description of changes:
Add ability for users to configure TES error cache expire time
Why is this change necessary:
How was this change tested:
Any additional information or context required to review the change:
Documentation Checklist:
Compatibility Checklist:
any deprecated method or type.
Refer to Compatibility Guidelines for more information.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.