-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Refactor cluster manager init sequence. #33221
Refactor cluster manager init sequence. #33221
Conversation
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
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.
The set of dependencies leading to the need to break the reference circle might benefit from some rethinking longer term, but this seems OK to me. @wbpcode you were interested in reviewing this as well.
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
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.
Thanks for your contribution. This seems good to me. (Although I cannot ensure it completely resolve our problem, the status is very complex when doing the initialization. But now it at least better then original condition)
source/server/configuration_impl.cc
Outdated
|
||
// clusterManagerFromProto() and init() have to be called consecutively. | ||
cluster_manager_ = cluster_manager_factory.clusterManagerFromProto(bootstrap); | ||
RETURN_IF_NOT_OK(cluster_manager_->init(bootstrap)); |
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.
Not sure if this completely resolve our problem. This ensure the server context could always return a valid reference to the cluster manager. But what will happen when the upstream network filter or upstream http filter try to access the actual content of the cluster manager when doing the initialization?
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.
Thanks for the comments!
-
When router filter is trying to call processFilters() for upstream filters:
envoy/source/common/router/router.cc
Line 108 in 63bc9b5
context.serverFactoryContext().clusterManager(), *upstream_ctx_, prefix);
it does access context.serverFactoryContext().clusterManager(). IIUC, this is in the much later stage, so the cluster manager instance is already initialized. -
In the ClusterInfoImpl c'tor, which is called during cluster_manager_->init()
envoy/source/common/upstream/upstream_impl.cc
Line 1376 in 63bc9b5
factory_context.clusterManager(), upstream_context_, prefix);
factory_.clusterFromProto(cluster, *this, outlier_event_logger_, added_via_api); |
It's accessing the cluster_manager_, i.e, *this, before it is initialized. This means ClusterInfoImpl c'tor only needs an instance of cluster manager, and does not require it is initialized.
Unfortunately, for composite filter in upstream chain case, it needs to access the cluster_manager_ from from outside here:
factory_context, server_factory_context.clusterManager(), false, "http", nullptr); |
That's the reason we need to make sure the server_factory_context.clusterManager() is setup before it is initialized.
BTW, for composite filter in upstream case, it also only needs an instance of cluster manager, and does not require it is initialized.
Please check the CI. Then we can try to merge it and see the effect :) |
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
LGTM, Thanks for your update. Could you check the CI then we can merge this PR. |
/retest |
1 similar comment
/retest |
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
/retest |
CI is complaining below. Should be non-related to this change. Code coverage for source/common/stats is lower than limit of 96.6 (96.5) |
…tor_cluster_manager Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
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.
LGTM. thanks for this contribution. cc @htuch for final pass or merge.
Kind ping! |
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.
LGTM, thanks!
- sync files - add `# unique` in .bazelrc to avoid CI failure https://dev.azure.com/cncf/4684fb3d-0389-4e0b-8251-221942316e06/_apis/build/builds/168119/logs/57 - add `cluster_manager_->initialize(bootstrap_);` to fix a CI crash which is introduced by envoyproxy/envoy#33221 Signed-off-by: Qin Qin <qqin@google.com>
This is to address the issue: envoyproxy#33218 Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
This is to address the issue: #33218
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]