-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
cluster manager: dynamically inserted clusters should be warming at first #12670
Comments
I think this is a duplicate of #11120 or a more general solution to it? Can we track this issue in one place? |
@mattklein123 I think that this is a part of #11120. So not duplicate. More general solution is required. This issue should be focused on Cluster Management. And #11120 should be focused on SDS. In my thought, we should track the changes of behavior of dynamically inserted cluster in this issue. |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions. |
/nostale |
This is related issue of #11120.
I think that the startup behavior of clusters which are triggered by
addOrUpdate()
is strange.Facing problem is that dynamically inserted cluster which depends on SDS is always
active
even though depending TLS certificate is not initialized because some of issue occurred, like there is no cert info on DiscoveryResponse.I think that this problem is caused by current behavior of ClusterManager. In current implementation, clusters inserted dynamically before all of init clusters haven't initialized will be marked immediately
active
. As a result, there is no indicator that inserted cluster is active or warming.In this situation, dynamically inserted cluster (calls
cluster_1
) should walk state change like,cluster_1
iswarming
whenaddOrUpdate()
is called before all of init clusters are not initialized.cluster_1
's transport socket factory is send DiscoveryRequest repeatedly until it reaches toinitial_fetch_timeout
, and stats is indicatingwarming
. When it retrieved TLS certificate, the state ofcluster_1
should change fromwarming
toactive
.initial_fetch_timeout
and there is no certificate, stats should indicatecluster_1
iswarming
eternally.It may be wrong understanding about cluster manager. But I think that we need to consider the initializing cluster's state change to resolve this problem.
cc. @howardjohn
The text was updated successfully, but these errors were encountered: