Skip to content

Conversation

@JeremyDahlgren
Copy link
Contributor

@JeremyDahlgren JeremyDahlgren commented Aug 20, 2025

Moves all remaining settings and supporting methods into RemoteClusterSettings and introduces a configuration interface LinkedProjectConfig with record types for proxy and sniff configurations. RemoteClusterSettings has static helper methods to build the config instances from 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 in CPS.

Resolves: ES-12656, ES-12569

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
@JeremyDahlgren JeremyDahlgren added :Distributed Coordination/Network Http and internode communication implementations >refactoring Team:Distributed Coordination Meta label for Distributed Coordination team v9.2.0 labels Aug 20, 2025
@JeremyDahlgren JeremyDahlgren requested a review from ywangd August 20, 2025 23:42
Copy link
Member

@ywangd ywangd left a 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.

@JeremyDahlgren JeremyDahlgren changed the title Use LinkedProjectConfig record in RemoteClusterService Use LinkedProjectConfig in RemoteClusterService Aug 21, 2025
@JeremyDahlgren JeremyDahlgren marked this pull request as ready for review August 22, 2025 19:58
@JeremyDahlgren JeremyDahlgren requested a review from a team as a code owner August 22, 2025 19:58
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination)

Copy link
Member

@ywangd ywangd left a 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!

Comment on lines 183 to 187
private Builder(ProjectId originProjectId, ProjectId linkedProjectId, String linkedProjectAlias) {
originProjectId(originProjectId);
linkedProjectId(linkedProjectId);
linkedProjectAlias(linkedProjectAlias);
}
Copy link
Member

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?

  1. Can connectionStrategy, i.e. mode, also be decided upfront and passed as a constructor argument?
  2. If we do the above, we should be able to configure the default maxNumConnections conditionally based on the connectionStrategy so that there is no need to have separate sniffMaxNumConnections and proxyNumSocketConnections fields (and methods)?
  3. The value of connectionStrategy can be used to validate whether builder method is should be called, e.g. if the strategy is proxy, the sniffSeedNodes should throw exception.
  4. Can we make all field passed in constructor final? It does not seem reasonable to change these fields, e.g. originalProjectId or connectionStrategy in following build methods?

Copy link
Contributor Author

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.

Copy link
Member

@ywangd ywangd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Great stuff!

@JeremyDahlgren JeremyDahlgren merged commit 5383ebe into elastic:main Aug 27, 2025
33 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Distributed Coordination/Network Http and internode communication implementations >refactoring Team:Distributed Coordination Meta label for Distributed Coordination team v9.2.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants