-
Notifications
You must be signed in to change notification settings - Fork 24.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
Introduce formal role for remote cluster client #53924
Introduce formal role for remote cluster client #53924
Conversation
This commit introduce a formal role for identifying nodes that are capable of making connections to remote clusters.
Pinging @elastic/es-distributed (:Distributed/Distributed) |
Pinging @elastic/es-core-infra (:Core/Infra/Core) |
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 question
public static Set<DiscoveryNodeRole> BUILT_IN_ROLES = Set.of(DATA_ROLE, INGEST_ROLE, MASTER_ROLE); | ||
public static Set<DiscoveryNodeRole> BUILT_IN_ROLES = Set.of(DATA_ROLE, INGEST_ROLE, MASTER_ROLE, REMOTE_CLUSTER_CLIENT_ROLE); | ||
|
||
static Set<DiscoveryNodeRole> LEGACY_ROLES = Set.of(DATA_ROLE, INGEST_ROLE, MASTER_ROLE); |
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.
Shouldn't this be based on version? At what point would this get updated? Perhaps we could use a map of role to min version (or a predicate) and iterate over them checking each role when serializing against the version of the output stream?
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.
No, this shouldn't be based on version. We have two things:
- very old nodes before we made roles pluggable that only understand three roles: master, data, and ingest
- new nodes after we made roles pluggable that understand the roles they are built with us, but also understand that other nodes might send them roles that they don't understand
- for example, a 7.6.0 node today while it doesn't have a role built-in for
remote_cluster_client
, does have the ability to receive that role from a 7.7.0 node, and represent it accordingly - however, a 7.0.0 node, before we made roles pluggable, has no possibility of understanding a
remote_cluster_client
role, it would blow up if it sees it
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 explanation
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
public static Set<DiscoveryNodeRole> BUILT_IN_ROLES = Set.of(DATA_ROLE, INGEST_ROLE, MASTER_ROLE); | ||
public static Set<DiscoveryNodeRole> BUILT_IN_ROLES = Set.of(DATA_ROLE, INGEST_ROLE, MASTER_ROLE, REMOTE_CLUSTER_CLIENT_ROLE); | ||
|
||
static Set<DiscoveryNodeRole> LEGACY_ROLES = Set.of(DATA_ROLE, INGEST_ROLE, MASTER_ROLE); |
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 explanation
This commit introduce a formal role for identifying nodes that are capable of making connections to remote clusters.
This commit introduce a formal role for identifying nodes that are capable of making connections to remote clusters. Relates #53924
) The primary shards of follower indices during the bootstrap need to be on nodes with the remote cluster client role as those nodes reach out to the corresponding leader shards on the remote cluster to copy Lucene segment files and renew the retention leases. This commit introduces a new allocation decider that ensures bootstrapping follower primaries are allocated to nodes with the remote cluster client role. Relates #54146 Relates #53924 Closes #58534 Co-authored-by: Jason Tedor <[email protected]>
…stic#59375) The primary shards of follower indices during the bootstrap need to be on nodes with the remote cluster client role as those nodes reach out to the corresponding leader shards on the remote cluster to copy Lucene segment files and renew the retention leases. This commit introduces a new allocation decider that ensures bootstrapping follower primaries are allocated to nodes with the remote cluster client role. Relates elastic#54146 Relates elastic#53924 Closes elastic#58534 Co-authored-by: Jason Tedor <[email protected]>
This commit introduce a formal role for identifying nodes that are capable of making connections to remote clusters.