Refactor cluster manager init sequence.#33221
Conversation
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
|
|
||
| // 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.
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.
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
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
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:
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>
|
Kind ping! |
- 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>
3 participants
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:]