-
Notifications
You must be signed in to change notification settings - Fork 25.5k
CCS metadata is opt-in in ESQL JSON responses #114437
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
Conversation
Documentation preview: |
Pinging @elastic/es-analytical-engine (Team:Analytics) |
x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/action/EsqlExecutionInfo.java
Outdated
Show resolved
Hide resolved
Couple of nitpicks, otherwise LGTM. |
When I add a new ESQL option/flag like And for that matter should the CCS metadata feature in general (added in earlier PR) be listed as either a capability or a feature in those classes? |
…etadata to MultiClustersIT and CrossClustersQueryIT
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.
In EsqlMediaTypeParser
we make a validation that considers the a combination of format and the columnar
parameter value in the sense that columnar
doesn't make sense to be used with any format. I think include_ccs_metadata
parameter is of the same type: it can only be used for json
format and I think we need a similar check.
Map<String, Object> resp = runEsql(new RestEsqlTestCase.RequestObjectBuilder().query(query).build()); | ||
private Map<String, Object> run(String query, boolean includeCCSMetadata) throws IOException { | ||
Map<String, Object> resp = runEsql( | ||
new RestEsqlTestCase.RequestObjectBuilder().query(query).includeCCSMetadata(includeCCSMetadata).build() |
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.
Using include_ccs_metadata
only on this IT test suite is not enough I think.
Users can use include_ccs_metadata
on any kind of REST request (multi cluster, single cluster single node, multi-node, mixed version, json/txt/tsv formats). I would, also, double check that "columnar": true
(see this one in docs) still works with this new addition to the JSON response.
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 would, also, double check that
"columnar": true
still works with this new addition to the JSON response.
It does. I tested it manually and I have added a test to MultiClustersIT that uses columnar format with include_ccs_metadata=true
and it is passing.
I think include_ccs_metadata parameter is of the same type: it can only be used for json format and I think we need a similar check
OK, I can add this restriction. If later we want to support it with SMILE, YAML and CBOR we can relax it.
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 have added a restriction that include_ccs_metadata
can only be used with format=JSON. Tests have been added / updated to match this restriction.
…Metadata and ensure correctly set on the EsqlExecutionInfo
…mat=JSON. Tests have been added / updated to match this restriction.
...l/src/internalClusterTest/java/org/elasticsearch/xpack/esql/action/CrossClustersQueryIT.java
Show resolved
Hide resolved
} | ||
|
||
private static void validateIncludeCCSMetadata(boolean includeCCSMetadata, MediaType fromMediaType) { | ||
if (includeCCSMetadata && fromMediaType != XContentType.JSON) { |
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 think it's ok so long as the media type isn't text like the instanceof
above. I expect kibana will use one of the binary ones at some point.
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.
OK, in the latest commit I've changed it to be like columnar
and work with any XContent type.
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 with one small addition, if you think it's worth it:
- in
x-pack/plugin/esql/qa/server/single-node/src/javaRestTest/java/org/elasticsearch/xpack/esql/qa/single_node/RestEsqlIT.java
if you can add one test that doesn't use the ccs remote cluster format for indices. You could also simply adjusttestBasicEsql()
test method to receive a random value forinclude_ccs_metadata
. This is to test a simple query likefrom test_index
(no CCS involved) that behaves normally in the presence ofinclude_ccs_metadata
.
Thanks, @quux00 👍
Map<String, Object> resp = runEsql( | ||
new RestEsqlTestCase.RequestObjectBuilder().query(query).includeCCSMetadata(true).columnar(true).build() | ||
); | ||
logger.info("--> query {} response {}", query, resp); |
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.
Leftover?
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.
No, I'm still using that method to have a test that does both columnar: true and includes_ccs_metadata:true.
@elasticmachine run elasticsearch-ci/part-3 |
@elasticmachine run Elasticsearch Serverless Checks |
buildkite test this |
@elasticmachine run elasticsearch-ci/rest-compatibility |
@elasticmachine run elasticsearch-ci/validate-changelogs |
💔 Backport failed
You can use sqren/backport to manually backport by running |
Since Kibana only needs CCS metadata in ESQL responses from certain well-defined locations, we are making CCS metadata opt-in. This feature is patterned after ESQL profiling, where you specify "profile": true in the ESQL body and if you asked for it will be present in the response always (it will be written to the .async-search index and you can’t turn it off in later async-search requests against this particular query ID) and if you didn’t ask for it at the beginning it will never be present (it will NOT be written to the .async-search index when it is persisted). The new option is "include_ccs_metadata": true/false.
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
Since Kibana only needs CCS metadata in ESQL responses from certain well-defined locations, we are making CCS metadata opt-in. This feature is patterned after ESQL profiling, where you specify "profile": true in the ESQL body and if you asked for it will be present in the response always (it will be written to the .async-search index and you can’t turn it off in later async-search requests against this particular query ID) and if you didn’t ask for it at the beginning it will never be present (it will NOT be written to the .async-search index when it is persisted). The new option is "include_ccs_metadata": true/false. (cherry picked from commit fd9d733) # Conflicts: # server/src/main/java/org/elasticsearch/TransportVersions.java
Since Kibana only needs CCS metadata in ESQL responses from certain well-defined locations, we are making CCS metadata opt-in. This feature is patterned after ESQL profiling, where you specify "profile": true in the ESQL body and if you asked for it will be present in the response always (it will be written to the .async-search index and you can’t turn it off in later async-search requests against this particular query ID) and if you didn’t ask for it at the beginning it will never be present (it will NOT be written to the .async-search index when it is persisted). The new option is "include_ccs_metadata": true/false. (cherry picked from commit fd9d733)
## Summary Retrieves the cluster details info on demand. Follow up of elastic/elasticsearch#114437 This will display the cluster details info only when needed: - Discover inspector - Lens ES|QL charts inspector
…6105) ## Summary Retrieves the cluster details info on demand. Follow up of elastic/elasticsearch#114437 This will display the cluster details info only when needed: - Discover inspector - Lens ES|QL charts inspector (cherry picked from commit fbe15fe)
) (#196511) # Backport This will backport the following commits from `main` to `8.x`: - [[ES|QL] Retrieves ccs information for inspector on demand (#196105)](#196105) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Stratoula Kalafateli","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-10-16T09:39:00Z","message":"[ES|QL] Retrieves ccs information for inspector on demand (#196105)\n\n## Summary\r\n\r\nRetrieves the cluster details info on demand. Follow up of\r\nhttps://github.com/elastic/elasticsearch/pull/114437\r\n\r\nThis will display the cluster details info only when needed:\r\n- Discover inspector\r\n- Lens ES|QL charts inspector","sha":"fbe15fe7886102c1203c18ff87f3a0ea72e4b581","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","backport:prev-minor","Feature:ES|QL","Team:ESQL","v8.16.0"],"title":"[ES|QL] Retrieves ccs information for inspector on demand","number":196105,"url":"https://github.com/elastic/kibana/pull/196105","mergeCommit":{"message":"[ES|QL] Retrieves ccs information for inspector on demand (#196105)\n\n## Summary\r\n\r\nRetrieves the cluster details info on demand. Follow up of\r\nhttps://github.com/elastic/elasticsearch/pull/114437\r\n\r\nThis will display the cluster details info only when needed:\r\n- Discover inspector\r\n- Lens ES|QL charts inspector","sha":"fbe15fe7886102c1203c18ff87f3a0ea72e4b581"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/196105","number":196105,"mergeCommit":{"message":"[ES|QL] Retrieves ccs information for inspector on demand (#196105)\n\n## Summary\r\n\r\nRetrieves the cluster details info on demand. Follow up of\r\nhttps://github.com/elastic/elasticsearch/pull/114437\r\n\r\nThis will display the cluster details info only when needed:\r\n- Discover inspector\r\n- Lens ES|QL charts inspector","sha":"fbe15fe7886102c1203c18ff87f3a0ea72e4b581"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Stratoula Kalafateli <[email protected]>
Since Kibana only needs CCS metadata in ESQL responses from certain well-defined locations, we are making CCS metadata opt-in. This feature is patterned after ESQL profiling, where you specify "profile": true in the ESQL body and if you asked for it will be present in the response always (it will be written to the .async-search index and you can’t turn it off in later async-search requests against this particular query ID) and if you didn’t ask for it at the beginning it will never be present (it will NOT be written to the .async-search index when it is persisted). The new option is "include_ccs_metadata": true/false.
Since Kibana only needs CCS metadata in ESQL responses from certain well-defined locations,
we are making CCS metadata opt-in. This feature is be patterned after ESQL profiling, where
you specify "profile": true in the ESQL body and if you asked for it will be present in the response
always (it will be written to the .async-search index and you can’t turn it off in later async-search
requests against this particular query ID) and if you didn’t ask for it at the beginning it will never
be present (it will NOT be written to the .async-search index when it is persisted).
The new option is "include_ccs_metadata": true/false.