New features and options in mixed-versions cross cluster search #70784
Comments
jimczi
added
>enhancement
:Search/Search
|
Pinging @elastic/es-search (Team:Search) |
jimczi
changed the title
|
In this discussion, we should include cases where Kibana is querying multiple remote clusters which are each on different Elasticsearch versions (I've only been testing a case with one remote cluster on a different version than the local Kibana/Elasticsearch cluster). |
This change adds a test module called `error-query` that exposes a
query builder to simulate errors and warnings on shard search request.
The query accepts a list of indices and shard ids where errors or warnings
should be reported:
```
POST test*/_search
{
"query": {
"error_query": {
"indices": [
{
"name": "test_exception",
"shard_ids": [1],
"error_type": "exception",
"message": "boom"
},
{
"name": "test_warn*",
"error_type": "warning",
"message": "Watch out!"
}
]
}
}
}
```
The `error_type` can be set to `exception` or `warning` and the `name` accepts
simple patterns, aliases and fully qualified index name if the search targets remote shards.
This module is published only within snapshots like the other test modules.
Relates elastic#70784
…71674) This change adds a test module called `error-query` that exposes a query builder to simulate errors and warnings on shard search request. The query accepts a list of indices and shard ids where errors or warnings should be reported: ``` POST test*/_search { "query": { "error_query": { "indices": [ { "name": "test_exception", "shard_ids": [1], "error_type": "exception", "message": "boom" }, { "name": "test_warn*", "error_type": "warning", "message": "Watch out!" } ] } } } ``` The `error_type` can be set to `exception` or `warning` and the `name` accepts simple patterns, aliases and fully qualified index name if the search targets remote shards. This module is published only within snapshots like the other test modules. Relates #70784
…lastic#71674) This change adds a test module called `error-query` that exposes a query builder to simulate errors and warnings on shard search request. The query accepts a list of indices and shard ids where errors or warnings should be reported: ``` POST test*/_search { "query": { "error_query": { "indices": [ { "name": "test_exception", "shard_ids": [1], "error_type": "exception", "message": "boom" }, { "name": "test_warn*", "error_type": "warning", "message": "Watch out!" } ] } } } ``` The `error_type` can be set to `exception` or `warning` and the `name` accepts simple patterns, aliases and fully qualified index name if the search targets remote shards. This module is published only within snapshots like the other test modules. Relates elastic#70784
…71674) (#72793) This change adds a test module called `error-query` that exposes a query builder to simulate errors and warnings on shard search request. The query accepts a list of indices and shard ids where errors or warnings should be reported: ``` POST test*/_search { "query": { "error_query": { "indices": [ { "name": "test_exception", "shard_ids": [1], "error_type": "exception", "message": "boom" }, { "name": "test_warn*", "error_type": "warning", "message": "Watch out!" } ] } } } ``` The `error_type` can be set to `exception` or `warning` and the `name` accepts simple patterns, aliases and fully qualified index name if the search targets remote shards. This module is published only within snapshots like the other test modules. Relates #70784
For this scenario we have decided that we will no longer skip unsupported features/options when serializing to older version nodes. We have adopted a different approach which consists of throwing exception instead, so that consumers are notified that a certain feature is not supported on some of the clusters/nodes involved. The only situation where we would not throw exception is in case we can emulate the feature/option that is not supported on older nodes. |
|
We have updated the cross-cluster search compatibility policy to support communicating with versions no older than the previous minor , which allows clients like Kibana to adopt new features/options safely one minor version after Elasticsearch released it. To help Kibana enforce that only CCS compatible features are used we have developed a testing flag (see #81809) that verifies the compatibility of incoming requests with the previous minor version. Also, we have changed our internal policy on how to make serialization changes: fail rather than silently ignore unsupported features/options when serializing to older version nodes, and we are discussing on #85456 whether the updated CCS compatibility policy should be enforced as it's not today. We have discussed this with the team and decided that there is nothing more to discuss on this topic and we can go ahead and close this issue. |
Cross-cluster search allows to query a remote cluster that can be on a different version than the local cluster.
The cluster responsible to send the remote request can be on 7.12 for instance and the remote cluster on 6.8.
The logic to send a query to such configuration should be to use features and options that are available on 6.8.
However it is complex for clients, even internally (Kibana), to detect these cases consistently.
The first issue is that we don't have a consistent way to handle a feature in the search API that is not available in a remote server. When we detect this in the transport layer, most of the time we act as if the option was not there. That's a case of silent breakage.
In such case I can see two options:
The skip part could be useful in a best effort scenario. For instance the
case_insensitiveoption of the terms queries could be skipped in older nodes, we'd return matches without applying the option and the warning in the response would indicate which shard/index is concerned.The error path would be reserved for cases where there is no other alternative. The error message can be clear and should mention the feature that the old node cannot handle.
I opened the issue to discuss how we can consistently add new options and features compatible with cross cluster search.
Having a clear warning/error for the mixed-version case would help to clarify why something is broken. That also shifts the responsibility to Elasticsearch to provide a comprehensive message on this complex configuration.
The text was updated successfully, but these errors were encountered: