-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Use LinkedProjectConfig in RemoteClusterService
#133266
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
Use LinkedProjectConfig in RemoteClusterService
#133266
Conversation
Moves all remaining settings and supporting methods into RemoteClusterSettings and introduces a configuration record type LinkedProjectConfig that can be built from the settings. Refactors RemoteClusterService and the related classes to use the LinkedProjectConfig, with settings extraction at higher levels in RemoteClusterService and RemoteClusterAware and its subclasses. This is another step towards supporting multiple origin projects with linked project configuration built from cluster state ProjectCustom updates. Resolves: ES-12656, ES-12569
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.
Overall looks good. I have some minor comments.
server/src/main/java/org/elasticsearch/transport/RemoteClusterService.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/transport/RemoteClusterService.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/transport/LinkedProjectConfig.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/transport/LinkedProjectConfig.java
Outdated
Show resolved
Hide resolved
LinkedProjectConfig record in RemoteClusterServiceLinkedProjectConfig in RemoteClusterService
|
Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
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.
Looking great. I have some more comments. I understand that the Builder can still be viewed as work-in-progress since it will need to accomodate the new ProjectCustom. So please free feel to pick and choose my suggestions for it. Thanks!
server/src/main/java/org/elasticsearch/transport/LinkedProjectConfig.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/transport/LinkedProjectConfig.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/transport/RemoteClusterSettings.java
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/transport/LinkedProjectConfig.java
Outdated
Show resolved
Hide resolved
| private Builder(ProjectId originProjectId, ProjectId linkedProjectId, String linkedProjectAlias) { | ||
| originProjectId(originProjectId); | ||
| linkedProjectId(linkedProjectId); | ||
| linkedProjectAlias(linkedProjectAlias); | ||
| } |
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.
I am really torn on how this builder should work. I am not a big fan of having a single builder for both config classes so that my intuition is to go with a base builder and subclasses. But that means using generic which adds complexity and may not worth it since we have only two variants. So I think we can stick with this current approach. But can we make it a bit stricter?
- Can
connectionStrategy, i.e.mode, also be decided upfront and passed as a constructor argument? - If we do the above, we should be able to configure the default
maxNumConnectionsconditionally based on theconnectionStrategyso that there is no need to have separatesniffMaxNumConnectionsandproxyNumSocketConnectionsfields (and methods)? - The value of
connectionStrategycan be used to validate whether builder method is should be called, e.g. if the strategy isproxy, thesniffSeedNodesshould throw exception. - Can we make all field passed in constructor
final? It does not seem reasonable to change these fields, e.g.originalProjectIdorconnectionStrategyin following build methods?
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.
I didn't like how a single build() function ended up requiring casts, so I refactored into builder subclasses. Let me know what you think of how it turned out.
server/src/main/java/org/elasticsearch/transport/LinkedProjectConfig.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/transport/LinkedProjectConfig.java
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/transport/RemoteClusterSettings.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/transport/RemoteConnectionStrategy.java
Outdated
Show resolved
Hide resolved
server/src/test/java/org/elasticsearch/transport/LinkedProjectConfigTests.java
Outdated
Show resolved
Hide resolved
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
Great stuff!
Moves all remaining settings and supporting methods into
RemoteClusterSettingsand introduces a configuration interfaceLinkedProjectConfigwith record types for proxy and sniff configurations.RemoteClusterSettingshas static helper methods to build the config instances from settings. RefactorsRemoteClusterServiceand the related classes to use theLinkedProjectConfig, with settings extraction at higher levels inRemoteClusterServiceandRemoteClusterAwareand its subclasses.This is another step towards supporting multiple origin projects with linked project configuration built from cluster state
ProjectCustomupdates in CPS.Resolves: ES-12656, ES-12569