mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-06 13:08:29 +00:00
45546e71c2
Adds GetRollupCaps API to the HLRC, and tweaks some of the Caps objects to be immutable. Also various style tweaks
84 lines
3.3 KiB
Plaintext
84 lines
3.3 KiB
Plaintext
--
|
|
:api: rollup-get-rollup-caps
|
|
:request: GetRollupCapsRequest
|
|
:response: GetRollupCapsResponse
|
|
--
|
|
|
|
[id="{upid}-x-pack-{api}"]
|
|
=== Get Rollup Capabilities API
|
|
|
|
The Get Rollup Capabilities API allows the user to query a target index pattern (`logstash-*`, etc)
|
|
and determine if there are any rollup jobs that are/were configured to rollup that pattern.
|
|
The API accepts a `GetRollupCapsRequest` object as a request and returns a `GetRollupCapsResponse`.
|
|
|
|
[id="{upid}-x-pack-{api}-request"]
|
|
==== Get Rollup Capabilities Request
|
|
|
|
A +{request}+ requires a single parameter: the target index or index pattern (e.g. `logstash-*`):
|
|
|
|
["source","java",subs="attributes,callouts,macros"]
|
|
--------------------------------------------------
|
|
include-tagged::{doc-tests-file}[x-pack-{api}-request]
|
|
--------------------------------------------------
|
|
|
|
[id="{upid}-x-pack-{api}-execution"]
|
|
==== Execution
|
|
|
|
The Get Rollup Capabilities API can be executed through a `RollupClient`
|
|
instance. Such instance can be retrieved from a `RestHighLevelClient`
|
|
using the `rollup()` method:
|
|
|
|
["source","java",subs="attributes,callouts,macros"]
|
|
--------------------------------------------------
|
|
include-tagged::{doc-tests-file}[x-pack-{api}-execute]
|
|
--------------------------------------------------
|
|
|
|
[id="{upid}-x-pack-{api}-response"]
|
|
==== Response
|
|
|
|
The returned +{response}+ holds lists and maps of values which correspond to the capabilities
|
|
of the target index/index pattern (what jobs were configured for the pattern, where the data is stored, what
|
|
aggregations are available, etc). It provides essentially the same data as the original job configuration,
|
|
just presented in a different manner.
|
|
|
|
For example, if we had created a job with the following config:
|
|
|
|
["source","java",subs="attributes,callouts,macros"]
|
|
--------------------------------------------------
|
|
include-tagged::{doc-tests-file}[x-pack-{api}-setup]
|
|
--------------------------------------------------
|
|
|
|
The +{response}+ object would contain the same information, laid out in a slightly different manner:
|
|
|
|
["source","java",subs="attributes,callouts,macros"]
|
|
--------------------------------------------------
|
|
include-tagged::{doc-tests-file}[x-pack-{api}-response]
|
|
--------------------------------------------------
|
|
|
|
[id="{upid}-x-pack-{api}-async"]
|
|
==== Asynchronous Execution
|
|
|
|
This request can be executed asynchronously:
|
|
|
|
["source","java",subs="attributes,callouts,macros"]
|
|
--------------------------------------------------
|
|
include-tagged::{doc-tests-file}[x-pack-{api}-execute-async]
|
|
--------------------------------------------------
|
|
<1> The +{request}+ to execute and the `ActionListener` to use when
|
|
the execution completes
|
|
|
|
The asynchronous method does not block and returns immediately. Once it is
|
|
completed the `ActionListener` is called back using the `onResponse` method
|
|
if the execution successfully completed or using the `onFailure` method if
|
|
it failed.
|
|
|
|
A typical listener for +{response}+ looks like:
|
|
|
|
["source","java",subs="attributes,callouts,macros"]
|
|
--------------------------------------------------
|
|
include-tagged::{doc-tests-file}[x-pack-{api}-execute-listener]
|
|
--------------------------------------------------
|
|
<1> Called when the execution is successfully completed. The response is
|
|
provided as an argument
|
|
<2> Called in case of failure. The raised exception is provided as an argument
|