We should not be constructing a temporary Environment object in production
code. This currently isn't causing any problems, but it might in the future
if elastic/elasticsearch#27144 or something similar is ever merged. Instead
the master Environment of the node should always be used.
Original commit: elastic/x-pack-elasticsearch@6276a54a45
This adds the data necessary to add a warning to the alerts UI representing each cluster when xpack.security.transport.tls.enabled is not set to true for a trial licensed cluster running with
xpack.security.enabled.
Original commit: elastic/x-pack-elasticsearch@28fe8bad76
* [DOCS] Add SSL info to setup-passwords
* [DOCS] Addressed feedback in setup-passwords
* [DOCS] Added link to setup-passwords troubleshooting page
Original commit: elastic/x-pack-elasticsearch@2bf820c303
This adds details about the shards and the health of the index. By adding these stats directly to the document, the UI can avoid many aggregations and enable better searching and sorting against indices.
Original commit: elastic/x-pack-elasticsearch@f38ae5ce69
This commit removes the FAILED state for the IndexAuditTrail so that we always try to keep starting
the service. Previously, on any exception during startup we moved to a failed state and never tried
to start again. The users only option was to restart the node. This was problematic in the case of
large clusters as there could be common timeouts of cluster state listeners that would cause the
startup of this service to fail.
Additionally, the logic in the IndexAuditTrail to update the template on the current cluster has
been removed and replaced with the use of the TemplateUpgradeService. However, we still need to
maintain the ability to determine if a template on a remote cluster should be PUT. To avoid always
PUTing the template, the version field has been added so it only needs to be PUT once on upgrade.
Finally, the default queue size has been increased as this is another common issue that users hit
with high traffic clusters.
relates elastic/x-pack-elasticsearch#2658
Original commit: elastic/x-pack-elasticsearch@27e2ce7223
* [DOCS] Enabled code snippet testing for put datafeed API
* [DOCS] Addressed gradle errors in put datafeed API
* [DOCS] Added job creation test to build.gradle
Original commit: elastic/x-pack-elasticsearch@3548d920c7
Adding this field enables a very simple mechanism for detecting node changes in the cluster state via Watcher (and other mechanisms). The next step is to add the cluster alert that uses it.
Original commit: elastic/x-pack-elasticsearch@1eacc25cff
This commit adds a new `certutil` command and deprecates the `certgen` command.
The new certuil consists of sub commands that are (by default) are simpler to use than the old monolithic command, but still support all the previous behaviours.
Original commit: elastic/x-pack-elasticsearch@3f57687da9
The execution state of a watch did not differentiate between failures of
the execution like a broken painless script and a thread pool rejection.
This adds an own state, which allows to aggregate on such data in the
watch history, which should ease debugging issues a bit.
Original commit: elastic/x-pack-elasticsearch@351e64e14d
For the purpose of getting this API consumed by our UI, returning
overall buckets that match the job's largest `bucket_span` can
result in too much data. The UI only ever displays a few buckets
in the swimlane. Their span depends on the time range selected and
the screen resolution, but it will only ever be a relatively
low number.
This PR adds the ability to aggregate overall buckets in a user
specified `bucket_span`. That `bucket_span` may be equal or
greater to the largest job's `bucket_span`. The `overall_score`
of the result overall buckets is the max score of the
corresponding overall buckets with a span equal to the job's
largest `bucket_span`.
The implementation is now chunking the bucket requests
as otherwise the aggregation would fail when too many buckets
are matching.
Original commit: elastic/x-pack-elasticsearch@981f7a40e5
If a bulk update references aliases rather than concrete indices,
it is possible that a single shard level request could have multiple distinct "index names", potentially including "date math".
Those names will resolve to the same concrete index, but they might have different privileges.
Original commit: elastic/x-pack-elasticsearch@34cfd11df8
lcawley
David Roberts
Chris Earle
Nik Everett
Jason Tedor
Albert Zaharovits
David Kyle
Tanguy Leroux
Jay Modi
Martijn van Groningen
Tim Vernum
Nhat
Alexander Reelsen
Hendrik Muhs
Dimitris Athanasiou
Lee Hinman
Simon Willnauer