Register CcrRepository based on settings update #35801
Conversation
Tim-Brooks
added
>non-issue
v7.0.0
:Distributed Indexing/CCR
|
Pinging @elastic/es-distributed |
| if (repositories == null) { | ||
| List<RepositoryMetaData> repositoriesMetaData = new ArrayList<>(clusters.size()); | ||
| for (String cluster : clusters) { | ||
| LOGGER.info("put [{}] repository [{}]", CcrRepository.TYPE, cluster); |
|
|
||
| if (repositories == null) { | ||
| List<RepositoryMetaData> repositoriesMetaData = new ArrayList<>(clusters.size()); | ||
| for (String cluster : clusters) { |
There was a problem hiding this comment.
instead of relying on a cached version, maybe parse the cluster state and get the current list of remote clusters? we can maybe add static methods in the RemoteClusterAware class to parse the settings into a whatever we need
|
|
||
| @Override | ||
| public void onMaster() { | ||
| this.isMasterNode = true; |
There was a problem hiding this comment.
instead of caching this - why not ask the cluster service if the current node is master every time we want to know? we already have a reference to it.
|
|
||
| @Override | ||
| protected void updateRemoteCluster(String clusterAlias, List<String> addresses, String proxyAddress) { | ||
| if (addresses.isEmpty()) { |
There was a problem hiding this comment.
wouldn't this method be called multiple times if multiple clusters changed?
|
|
||
| import static org.elasticsearch.test.hamcrest.ElasticsearchAssertions.assertAcked; | ||
|
|
||
| public class CcrRepositoryManagerIT extends CcrIntegTestCase { |
There was a problem hiding this comment.
Do we have to have an IntegTest for this? I presume we will future tests that will cover this and more? can't we have a unit tests that checks how the CCRRepositoryManager reacts to cluster state changes?
|
Closed in favor of approach in #36086. |
This commit adds an empty CcrRepository snapshot/restore repository.
When a new cluster is registered in the remote cluster settings, a new
CcrRepository is registered for that cluster. This is based on the
master nodes view of the settings. So if a new node becomes master, it
refreshes the repositories based on the remote clusters it is aware of.
The repository will be unregistered if the remote cluster is removed.