hcm: Add DependencyManager for http filterchain validation#15109
hcm: Add DependencyManager for http filterchain validation#15109htuch merged 24 commits intoenvoyproxy:mainfrom
Conversation
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
source/extensions/filters/network/http_connection_manager/BUILD
Outdated
Show resolved
Hide resolved
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
htuch
left a comment
There was a problem hiding this comment.
Thanks, make sense and looks good, just a few nits.
/wait
source/extensions/filters/network/http_connection_manager/BUILD
Outdated
Show resolved
Hide resolved
| * from the filter factory. Filters must be registered in decode path order. | ||
| */ | ||
| void registerFilter( | ||
| std::string name, |
There was a problem hiding this comment.
Is there any memory access risk to having a std::map keyed by absl::string_view? Does this introduce lifetime requirements on the filter factory?
There was a problem hiding this comment.
You probably want the map itself to have a string key, but use string_view here. This is why absl::flat_hash_map is great, as it has these polymorphic lookup methods.
There was a problem hiding this comment.
I misspoke, this is a std::vector<absl::string_view,...> not a map. Any issue with that?
source/extensions/filters/network/http_connection_manager/dependency_manager.h
Outdated
Show resolved
Hide resolved
source/extensions/filters/network/http_connection_manager/dependency_manager.h
Outdated
Show resolved
Hide resolved
source/extensions/filters/network/http_connection_manager/dependency_manager.cc
Outdated
Show resolved
Hide resolved
|
|
||
| bool DependencyManager::decodePathIsValid() { | ||
| auto cmp = [](Dependency a, Dependency b) { return a.name() != b.name(); }; | ||
| std::set<Dependency, decltype(cmp)> satisfied(cmp); |
There was a problem hiding this comment.
While I'd also prefer the absl library, it seems not to support the custom comparator API in the same way, and I'm going to avoid the hassle of figuring that out unless you feel strongly.
|
|
||
| bool DependencyManager::decodePathIsValid() { | ||
| auto cmp = [](Dependency a, Dependency b) { return a.name() != b.name(); }; | ||
| std::set<Dependency, decltype(cmp)> satisfied(cmp); |
There was a problem hiding this comment.
Why not just make this a absl::flat_hash_set<std::string>?
There was a problem hiding this comment.
Proto comparison doesn't work properly. In the future I'll probably switch this over to use message_differencer.h.
There was a problem hiding this comment.
For both this and the above point, I don't think we need to store the full dependency in the set, but just its name?
There was a problem hiding this comment.
I think I see what the issue is. You ideally are showing that the dependency matches the provider. You need to compare both name and also the DependencyType. However in this PR so far you only have name.
I suggest following the pattern of LocalityWeightsMap in eds.h for a pattern here around custom comparators, Absl, and proto keys.
There was a problem hiding this comment.
I looked at LocalityWeightsMap and talked to Ashley about it, and I think got a simpler way to do this. Since it seems an intermediary type is unavoidable, I went with this:
using DependencyTuple = std::tuple<const std::string&, int>;
absl::flat_hash_set<DependencyTuple> satisfied;
This isn't resilient to modifications to the Dependency proto but I don't really anticipate more fields being added so I think this works for now.
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
|
@auni53 looks good, I think maybe if you can add support for dealing with dependency type matching that would complete this for the decode path. Thanks. |
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
aunu53
left a comment
There was a problem hiding this comment.
OK, was able to incorporate absl flat hash set and simplified the comparator logic. I reordered/renamed the unit tests while adding functionality around dependency type checking.
| * from the filter factory. Filters must be registered in decode path order. | ||
| */ | ||
| void registerFilter( | ||
| std::string name, |
There was a problem hiding this comment.
I misspoke, this is a std::vector<absl::string_view,...> not a map. Any issue with that?
Signed-off-by: Auni Ahsan <auni@google.com>
htuch
left a comment
There was a problem hiding this comment.
LGTM modulo small nit. Thanks for the cleanups.
/wait
| bool validDecodeDependencies(); | ||
|
|
||
| private: | ||
| std::vector<std::pair<absl::string_view, |
There was a problem hiding this comment.
For safety I'd make this an std::string. What I mentioned before was about parameters, the persistent structure should avoid holding a string view.
There was a problem hiding this comment.
Yeah the polymorphism is not working here:
dependency_manager.h:26:19: error: no matching member function for call to 'push_back'
filter_chain_.push_back({name, dependencies});
Probably I'd have to call whatever function copies the underlying string from absl::string_view, so I just changed it to const std::string& both in the function signature and the vector definition.
Signed-off-by: Auni Ahsan <auni@google.com>
source/extensions/filters/network/http_connection_manager/dependency_manager.h
Outdated
Show resolved
Hide resolved
Signed-off-by: Auni Ahsan <auni@google.com>
Signed-off-by: Auni Ahsan <auni@google.com>
|
/retest |
|
Retrying Azure Pipelines: |
Commit Message:
Risk Level: Low, this only adds a class and unit tests
See design doc attached to #14470 for more details.