Skip to content
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

[CCS] improve response when node is not allowed to open remote connections in CCS #37863

Closed
LucaWintergerst opened this issue Jan 25, 2019 · 7 comments · Fixed by #40419
Closed
Assignees
Labels
:Search/Search Search-related issues that do not fall into other categories

Comments

@LucaWintergerst
Copy link
Contributor

If a node has cluster.remote.connect: false configured, that node will behave in the following way:

Request: GET remote_cluster:*/_search
Response: {}

The node also does not log anything that would indicate that the setting is the cause of the empty response.
CCS should give additional output why the response is empty so this can be handled by the downstream applications. Otherwise this misconfiguration can be easy to miss and very hard to troubleshoot.

@dimitris-athanasiou and @droberts195 are happy to discuss and elaborate more if necessary
We caught this when we were troubleshooting why dedicated ML nodes were not working for a user

@LucaWintergerst LucaWintergerst added the :Search/Search Search-related issues that do not fall into other categories label Jan 25, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search

@javanna javanna self-assigned this Jan 29, 2019
@javanna
Copy link
Member

javanna commented Jan 30, 2019

heya @LucaWintergerst I don't see an empty response being returned. I rather get this (tested on 6.6.0):

{
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 0,
    "successful" : 0,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 0,
    "max_score" : 0.0,
    "hits" : [ ]
  }
}

The reason for this is that, when connecting to remote clusters is disabled, the node behaves as if the seeds were not configured and treats remote_cluster:* like a wildcard expression referring to local indices, which gets resolved to no indices. This is because there can be local indices matching that expression (see #26247 where we disallowed/deprecated using : in an index name), so we can't really assume that users are referring to a remote index and throw an error (we will be able to make that assumption in 8.0 only).

That said there are a couple of ways to detect that something is going wrong:

  • check _shards.total: 0 means the query did not run on any shards, which looks suspicious
  • use allow_no_indices=false,ignore_unavailable=false to have a strict behaviour, that way you get an exception whenever an index is mentioned that does not exist and the search fails

@dimitris-athanasiou @droberts195 could you let me know if this work for you?

@dimitris-athanasiou
Copy link
Contributor

@javanna While we could probably fix the ML side using your suggestions, I still think other users could be bitten by this. Would it not be possible to throw an error instead? It seems like we know we're reaching a remote cluster and we know the node is disabled from doing so, so why not error?

@javanna
Copy link
Member

javanna commented Jan 30, 2019

@dimitris-athanasiou I explained above why we cannot do it.

This is because there can be local indices matching that expression (see #26247 where we disallowed/deprecated using : in an index name), so we can't really assume that users are referring to a remote index and throw an error (we will be able to make that assumption in 8.0 only).

@dimitris-athanasiou
Copy link
Contributor

Ah, apologies, I misread that part.

@javanna
Copy link
Member

javanna commented Jan 30, 2019

No worries, I will take care of updating this behaviour once we move master to 8.0, for now I will close this issue.

@javanna
Copy link
Member

javanna commented Mar 25, 2019

Reopening, we moved master to 8.0.0 and it's now possible to make this change. PR coming.

@javanna javanna reopened this Mar 25, 2019
javanna added a commit to javanna/elasticsearch that referenced this issue Mar 25, 2019
Remote cluster resolution is currently lenient, to support local
indices that may contain `:` in their name. From 8.0 on, there can no
longer be indices in the cluster that contain `:` in their name, hence
we can make remote cluster resolution stricter. Instead of treating
any index expression containing a `:` whenever there is no corresponding
matching remote cluster registered, we now throw a
`NoSuchRemoteClusterException`.

Closes elastic#37863
javanna added a commit that referenced this issue Apr 4, 2019
Remote cluster resolution is currently lenient, to support local
indices that may contain `:` in their name. From 8.0 on, there can no
longer be indices in the cluster that contain `:` in their name, hence
we can make remote cluster resolution stricter. Instead of treating
any index expression containing a `:` whenever there is no corresponding
matching remote cluster registered, we now throw a
`NoSuchRemoteClusterException`.

Closes #37863
gurkankaymak pushed a commit to gurkankaymak/elasticsearch that referenced this issue May 27, 2019
Remote cluster resolution is currently lenient, to support local
indices that may contain `:` in their name. From 8.0 on, there can no
longer be indices in the cluster that contain `:` in their name, hence
we can make remote cluster resolution stricter. Instead of treating
any index expression containing a `:` whenever there is no corresponding
matching remote cluster registered, we now throw a
`NoSuchRemoteClusterException`.

Closes elastic#37863
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Search/Search Search-related issues that do not fall into other categories
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants