dynamic_modules: remote source: add nack_on_cache_miss#44044
dynamic_modules: remote source: add nack_on_cache_miss#44044wbpcode merged 4 commits intoenvoyproxy:mainfrom
Conversation
Signed-off-by: Anurag Aggarwal <kanurag94@gmail.com>
Signed-off-by: Anurag Aggarwal <kanurag94@gmail.com>
|
/retest |
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces the nack_on_cache_miss option for remote dynamic modules, enabling a non-blocking loading mechanism suitable for ECDS and per-route configurations. The changes are well-implemented, including clear documentation in the protobuf definition, a corresponding changelog entry, and a comprehensive set of tests that cover success, failure, and edge-case scenarios. The overall approach is sound. I have one minor suggestion to optimize a section of the code for better performance and readability.
Signed-off-by: Anurag Aggarwal <kanurag94@gmail.com>
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
| void DynamicModuleConfigFactory::BackgroundFetchState::onSuccess(const std::string& data) { | ||
| auto result = Extensions::DynamicModules::newDynamicModuleFromBytes(data, sha256_, do_not_close_, | ||
| load_globally_); | ||
| if (!result.ok()) { | ||
| ENVOY_LOG(error, "Failed to load background-fetched module: {}", result.status().message()); | ||
| } else { | ||
| ENVOY_LOG(info, "Background fetch complete, module cached for SHA256 {}", sha256_); | ||
| } | ||
| completed_ = true; | ||
| } |
There was a problem hiding this comment.
I guess the background fetcher only need to fetch the data, validate its hash, and write it to local file. We needn't try to load it because it make no sense I think?
There was a problem hiding this comment.
Make sense. It would have no real meaning. Thanks for catching this
wbpcode
left a comment
There was a problem hiding this comment.
I will say, great. Thanks for this great contribution and only two comments.
/wait
| // This lives on the factory (rather than a singletonManager singleton) because | ||
| // REGISTER_FACTORY already makes the factory a process-lifetime singleton, so a | ||
| // separate registration would just be boilerplate for the same semantics. | ||
| // Entries are erased in createFilterFactory(), never inside a fetch callback, | ||
| // which means the RemoteDataFetcher is never destroyed while it's still running. | ||
| absl::flat_hash_map<std::string, std::unique_ptr<BackgroundFetchState>> background_fetches_; |
There was a problem hiding this comment.
I guess we can make this a singleton because in the future, we may want to support similar feature for other dynamic modules (like network filter dym, logger dym and so on)
Signed-off-by: Anurag Aggarwal <kanurag94@gmail.com>
) <!-- !!!ATTENTION!!! If you are fixing *any* crash or *any* potential security issue, *do not* open a pull request in this repo. Please report the issue via emailing envoy-security@googlegroups.com where the issue will be triaged appropriately. Thank you in advance for helping to keep Envoy secure. !!!ATTENTION!!! For an explanation of how to fill out the fields, please see the relevant section in [PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/main/PULL_REQUESTS.md) !!!ATTENTION!!! Please check the [use of generative AI policy](https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md?plain=1#L41). You may use generative AI only if you fully understand the code. You need to disclose this usage in the PR description to ensure transparency. --> **Commit Message:** dynamic_modules: add nack_on_cache_miss for remote module sources **Additional Description:** This PR adds support for nacking a configuration if the dynamic module is not fetched and start a background fetch. The module may become available in the next config push and ready to use from cache. Entries are keyed by sha256 so that multiple listeners can use the same fetch. The cache lives inside the factory and is safe to be used across listeners. Completed entries are cleaned up on the next `createFilterFactory()` and not during a fetch callback. So that the `RemoteDataFetcher` is not destroyed mid-fetch. **Risk Leve**l: Low **Testing:** Unit tests added. Manually validated **Docs Changes**: Proto changes included **Release Notes:** Added [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] --------- Signed-off-by: Anurag Aggarwal <kanurag94@gmail.com> Signed-off-by: Xuyang Tao <taoxuy@google.com>
) <!-- !!!ATTENTION!!! If you are fixing *any* crash or *any* potential security issue, *do not* open a pull request in this repo. Please report the issue via emailing envoy-security@googlegroups.com where the issue will be triaged appropriately. Thank you in advance for helping to keep Envoy secure. !!!ATTENTION!!! For an explanation of how to fill out the fields, please see the relevant section in [PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/main/PULL_REQUESTS.md) !!!ATTENTION!!! Please check the [use of generative AI policy](https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md?plain=1#L41). You may use generative AI only if you fully understand the code. You need to disclose this usage in the PR description to ensure transparency. --> **Commit Message:** dynamic_modules: add nack_on_cache_miss for remote module sources **Additional Description:** This PR adds support for nacking a configuration if the dynamic module is not fetched and start a background fetch. The module may become available in the next config push and ready to use from cache. Entries are keyed by sha256 so that multiple listeners can use the same fetch. The cache lives inside the factory and is safe to be used across listeners. Completed entries are cleaned up on the next `createFilterFactory()` and not during a fetch callback. So that the `RemoteDataFetcher` is not destroyed mid-fetch. **Risk Leve**l: Low **Testing:** Unit tests added. Manually validated **Docs Changes**: Proto changes included **Release Notes:** Added [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] --------- Signed-off-by: Anurag Aggarwal <kanurag94@gmail.com> Signed-off-by: Jonathan Wu <jtwu@google.com>
) <!-- !!!ATTENTION!!! If you are fixing *any* crash or *any* potential security issue, *do not* open a pull request in this repo. Please report the issue via emailing envoy-security@googlegroups.com where the issue will be triaged appropriately. Thank you in advance for helping to keep Envoy secure. !!!ATTENTION!!! For an explanation of how to fill out the fields, please see the relevant section in [PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/main/PULL_REQUESTS.md) !!!ATTENTION!!! Please check the [use of generative AI policy](https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md?plain=1#L41). You may use generative AI only if you fully understand the code. You need to disclose this usage in the PR description to ensure transparency. --> **Commit Message:** dynamic_modules: add nack_on_cache_miss for remote module sources **Additional Description:** This PR adds support for nacking a configuration if the dynamic module is not fetched and start a background fetch. The module may become available in the next config push and ready to use from cache. Entries are keyed by sha256 so that multiple listeners can use the same fetch. The cache lives inside the factory and is safe to be used across listeners. Completed entries are cleaned up on the next `createFilterFactory()` and not during a fetch callback. So that the `RemoteDataFetcher` is not destroyed mid-fetch. **Risk Leve**l: Low **Testing:** Unit tests added. Manually validated **Docs Changes**: Proto changes included **Release Notes:** Added [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] --------- Signed-off-by: Anurag Aggarwal <kanurag94@gmail.com> Signed-off-by: Nick Shipilov <nick.shipilov.n@gmail.com>
) <!-- !!!ATTENTION!!! If you are fixing *any* crash or *any* potential security issue, *do not* open a pull request in this repo. Please report the issue via emailing envoy-security@googlegroups.com where the issue will be triaged appropriately. Thank you in advance for helping to keep Envoy secure. !!!ATTENTION!!! For an explanation of how to fill out the fields, please see the relevant section in [PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/main/PULL_REQUESTS.md) !!!ATTENTION!!! Please check the [use of generative AI policy](https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md?plain=1#L41). You may use generative AI only if you fully understand the code. You need to disclose this usage in the PR description to ensure transparency. --> **Commit Message:** dynamic_modules: add nack_on_cache_miss for remote module sources **Additional Description:** This PR adds support for nacking a configuration if the dynamic module is not fetched and start a background fetch. The module may become available in the next config push and ready to use from cache. Entries are keyed by sha256 so that multiple listeners can use the same fetch. The cache lives inside the factory and is safe to be used across listeners. Completed entries are cleaned up on the next `createFilterFactory()` and not during a fetch callback. So that the `RemoteDataFetcher` is not destroyed mid-fetch. **Risk Leve**l: Low **Testing:** Unit tests added. Manually validated **Docs Changes**: Proto changes included **Release Notes:** Added [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] --------- Signed-off-by: Anurag Aggarwal <kanurag94@gmail.com>
Commit Message: dynamic_modules: add nack_on_cache_miss for remote module sources
Additional Description:
This PR adds support for nacking a configuration if the dynamic module is not fetched and start a background fetch. The module may become available in the next config push and ready to use from cache.
Entries are keyed by sha256 so that multiple listeners can use the same fetch. The cache lives inside the factory and is safe to be used across listeners. Completed entries are cleaned up on the next
createFilterFactory()and not during a fetch callback. So that theRemoteDataFetcheris not destroyed mid-fetch.Risk Level: Low
Testing: Unit tests added. Manually validated
Docs Changes: Proto changes included
Release Notes: Added
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]