-
Notifications
You must be signed in to change notification settings - Fork 10.4k
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] Move global config alongside core configuration #30788
Conversation
Automated fix for refs/heads/environmental-pollution
Automated fix for refs/heads/environmental-pollution
…o environmental-pollution
Automated fix for refs/heads/environmental-pollution
…o environmental-pollution
Automated fix for refs/heads/environmental-pollution
src/core/ext/filters/client_channel/resolver/dns/dns_resolver_selection.h
Outdated
Show resolved
Hide resolved
@@ -61,19 +61,10 @@ static backup_poller* g_poller = nullptr; // guarded by g_poller_mu | |||
static grpc_core::Duration g_poll_interval = | |||
grpc_core::Duration::Milliseconds(DEFAULT_POLL_INTERVAL_MS); | |||
|
|||
GPR_GLOBAL_CONFIG_DEFINE_INT32( |
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 drawback of centralizing the definition of these config params is that it will be less obvious when there are no longer any users of a given parameter and it can be removed. Just as one example, prior to this PR, when we eventually remove this backup poller, this parameter would have been removed at the same time; with this PR, it might be easier to forget. Is there a reasonable way we can have some automated check for this kind of thing?
This isn't a blocker, but would be good to add some check for this if we have a reasonable way to do so.
@@ -55,9 +55,14 @@ int main(int argc, char** argv) { | |||
|
|||
grpc::testing::TestEnvironment env(&argc, argv); | |||
grpc_end2end_tests_pre_init(); | |||
<<<<<<< HEAD |
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.
Looks like some leftover cruft from a merge.
Automated fix for refs/heads/environmental-pollution
This reverts commit e5fea5f.
…o environmental-pollution
Automated fix for refs/heads/environmental-pollution
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.
Correct Cython the first try? Impossible.
LGTM to the src/python/**/*
changes.
This very likely break the ObjC bazel test: It started failing right after this PR got merged:
In fact, this was correctly indicated by the "ObjC Bazel Test" presubmit test (which is red on this PR). |
)" This reverts commit b7a8330.
…2659) Reverts #30788 (it breaks grpc_objc_bazel_test (see #30788 (comment)) and also seems to be breaking some other internal stuff).
This is a big rewrite of global config. It does a few things, all somewhat intertwined: 1. centralize the list of configuration we have to a yaml file that can be parsed, and code generated from it 2. add an initialization and a reset stage so that config vars can be centrally accessed very quickly without the need for caching them 3. makes the syntax more C++ like (less macros!) 4. (optionally) adds absl flags to the OSS build This first round of changes is intended to keep the system where it is without major changes. We pick up absl flags to match internal code and remove one point of deviation - but importantly continue to read from the environment variables. In doing so we don't force absl flags on our customers - it's possible to configure grpc without the flags - but instead allow users that do use absl flags to configure grpc using that mechanism. Importantly this lets internal customers configure grpc the same everywhere. Future changes along this path will be two-fold: 1. Move documentation generation into the code generation step, so that within the source of truth yaml file we can find all documentation and data about a configuration knob - eliminating the chance of forgetting to document something in all the right places. 2. Provide fuzzing over configurations. Currently most config variables get stashed in static constants across the codebase. To fuzz over these we'd need a way to reset those cached values between fuzzing rounds, something that is terrifically difficult right now, but with these changes should simply be a reset on `ConfigVars`. <!-- If you know who should review your pull request, please assign it to that person, otherwise the pull request would get assigned randomly. If your pull request is for a specific language, please add the appropriate lang label. --> --------- Co-authored-by: ctiller <ctiller@users.noreply.github.com>
…pc#32659) Reverts grpc#30788 (it breaks grpc_objc_bazel_test (see grpc#30788 (comment)) and also seems to be breaking some other internal stuff).
This is a big rewrite of global config. It does a few things, all somewhat intertwined: 1. centralize the list of configuration we have to a yaml file that can be parsed, and code generated from it 2. add an initialization and a reset stage so that config vars can be centrally accessed very quickly without the need for caching them 3. makes the syntax more C++ like (less macros!) 4. (optionally) adds absl flags to the OSS build This first round of changes is intended to keep the system where it is without major changes. We pick up absl flags to match internal code and remove one point of deviation - but importantly continue to read from the environment variables. In doing so we don't force absl flags on our customers - it's possible to configure grpc without the flags - but instead allow users that do use absl flags to configure grpc using that mechanism. Importantly this lets internal customers configure grpc the same everywhere. Future changes along this path will be two-fold: 1. Move documentation generation into the code generation step, so that within the source of truth yaml file we can find all documentation and data about a configuration knob - eliminating the chance of forgetting to document something in all the right places. 2. Provide fuzzing over configurations. Currently most config variables get stashed in static constants across the codebase. To fuzz over these we'd need a way to reset those cached values between fuzzing rounds, something that is terrifically difficult right now, but with these changes should simply be a reset on `ConfigVars`. <!-- If you know who should review your pull request, please assign it to that person, otherwise the pull request would get assigned randomly. If your pull request is for a specific language, please add the appropriate lang label. --> --------- Co-authored-by: ctiller <ctiller@users.noreply.github.com>
…2659) Reverts #30788 (it breaks grpc_objc_bazel_test (see #30788 (comment)) and also seems to be breaking some other internal stuff).
This is a big rewrite of global config.
It does a few things, all somewhat intertwined:
This first round of changes is intended to keep the system where it is without major changes. We pick up absl flags to match internal code and remove one point of deviation - but importantly continue to read from the environment variables. In doing so we don't force absl flags on our customers - it's possible to configure grpc without the flags - but instead allow users that do use absl flags to configure grpc using that mechanism. Importantly this lets internal customers configure grpc the same everywhere.
Future changes along this path will be two-fold:
ConfigVars
.