Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
config: Scoped RDS (PR 1/4): Introduce {static,dynamic} config provider framework #5243
config: Scoped RDS (PR 1/4): Introduce {static,dynamic} config provider framework #5243
Changes from 23 commits
6c744cd
1bccfaf
66e4c45
02b5e97
09a0846
acf19cf
c0366a7
4b1bef4
550723c
2c79e9c
854c2f2
e67b5ee
821aab9
ca583a0
15c9d19
f69eb74
ba44ad9
142d9c1
5c71955
7441143
a36a3e8
bb34fdd
ccc244a
6d7cba8
9cf7f27
58ac876
bb990fa
b49127f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
One high level question to kick this off with. Is the plan to also replace the static/dynamic treatment of SDS resoureces (e.g. see https://github.com/envoyproxy/envoy/blob/master/source/common/ssl/context_config_impl.cc#L57) with this class framework? It would be helpful to have in mind the concrete types that this will be instantiated with and places used when reading.
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.
Yes, SDS looks like a good candidate as well, although I was not planning to transition it to the new API as part of this PR chain so there are likely a few gaps that will need to be addressed.
One of those gaps is that the
ConfigProvider
currently only exposes astd::shared_ptr<const Config> config() const
function, but the SDS config impls require allowing the user/consumer of the API to set a callback (see ContextConfigImpl::setSecretUpdateCallback). From an API standpoint, I think the solution is trivial by exposing astd::shared_ptr<Config> config()
overload, and having the config impl enforce thread safety itself by leveraging any synchronization mechanisms required.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 think it would be ideal from a tech debt perspective if we could at least file an issue for this if not do the conversion at the end of the PR chain. There is a lot of commonality here between RDS and SDS, having multiple methods of managing static/dynamic resources seems redundant. Anyway, I'll do a deep dive now.
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.
Agreed, I'll file an issue to keep track of SDS. I plan to take a deeper look at it once I get through these PRs and will likely take on the work myself.
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.
Issue filed: #5329.
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 think I might be being dense here. However, this discussion and @lizan's comment here leave me with a few questions:
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.
Yeah, more emphasis on the shared aspect in this comment would make sense; a short sentence or two explaining where this fits into the taxonomy of configuration management in Envoy would be rad.
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.
Answering @junr03 's questions below:
Done.
This framework can also be leveraged for use cases where there is no expected sharing of dynamic resources, since that use case is a simplification of the target use case and the publicly exposed ConfigProvider API should suffice as well. However, I have avoided introducing this framework as the solution for config management, since it's likely that some of these "singly owned" use cases could make due with simpler implementations than what is imposed by this framework.
I have changed the naming of the *ImplBase classes and added comments to clarify how this framework can be leveraged for SDS as well and the static/inline distinction that it makes. Essentially, the
ImmutableConfigProviderImplBase
can satisfy both config types, and I've introduced aConfigProviderInstanceType
parameter to the constructor to distinguish between them.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.
Done.
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:
absl::nullopt
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.
Done.
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.
Searching around for what this does, it seems to involve side-effects, which I don't see at the sites where it is used. Can you add some comments on when you need to use this?
Alternatively, can we just fold these pragmas into
ASSERT
? Fewer knobs here seems better, we could potentially have an unbounded number of theseASSERT
s, one for each clang warning :DThere 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.
The comment in https://github.com/envoyproxy/envoy/pull/5243/files#diff-0bbc1b7ef8d5cfd41d41b2296caf7f1fR65 attempts to address the reason for this assert: the
typeid(**mutable_config_providers_.begin())
statement triggers the potentially evaluated warning in clang.This seems like a useful enough warning that I would rather not hide it by default (by folding it into the ASSERT() macro), but if others feel strongly about this I am certainly open to doing so.
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.
Well, I guess I'm still not a huge fan of adding compiler specific ASSERTs into the implementation here. @envoyproxy/maintainers WDYT?
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.
Hmm, if we do assert like this (evaluate the expression outside of
typeid
) then we don't need the pragma at all, since it is no longer potentially evaluated expression, do you think this is cleaner?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 is a good solution; I definitely think it's cleaner overall even though it makes the ASSERT() slightly harder to parse. I just pushed this change and removed my changes to assert.h. Thanks!
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 loop looks wrong based on a quick glance; the
new_config
nullness gets shared across dynamic providers... unlessonConfigProtoUpdate
is identical across them all? If so, please add comments and maybe ASSERTs.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.
These dynamic providers are all instances of the same class, and they share the underlying ConfigSubscriptionInstance on which this function is taking effect.
I will add the comments and assert()s.
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.
Added comments and an ASSERT to bindConfigProvider(). The assertion is tricky due to the lack of concrete type information in these functions, so PTAL and let me know your thoughts on my approach using RTTI.
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.
FWIW, the new naming scheme is also a bit confusing, since the config object that is provided is always immutable, but the fact that a new config can be swapped in is being assigned the mutability characteristic. IDK if it's worth bike shedding further on this, but just raising this as a potential reader confusion.
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 added to the file level comment more details regarding the mutability property and how it applies in this context.
I am open to considering other names but this is the best I have come up with given the constraints pointed out by @lizan related to naming conventions already in place for the concrete classes.