The watcher index uses auto expanding of replicas nowadays, so there is
no need to set the number of replicas.
Also ensuring that all watcher indices are green on startup has been moved
to one call, in order to prevent indices being moved around after adding
the triggered watches or watch history index.
Original commit: elastic/x-pack-elasticsearch@dbe04adf64
* Add fields to `.logstash`'s mapping in template
This "makes room" in the index for pipeline settings and node groups. Due to this change, users will be able to specify settings and node groups for a pipeline via the Centralized Config Management UI in Kibana. Logstash will only retrieve pipelines associated with the node group specified via the `xpack.management.group.id` setting in `logstash.yml`. For the retrieved pipelines, Logstash will apply any (optionally) specified pipeline settings before (re)loading the pipelines.
* Making field name more explicit + adding multi field for better search
Original commit: elastic/x-pack-elasticsearch@2df101f0b1
This adds the `HEADERS_SETTING` as setting reported by the Monitoring plugin, which was changed in 6.2.
It also adds an IT to ensure that it is not missed in the future (existing integration tests were passing in the Settings and not being validated by the cluster!).
Original commit: elastic/x-pack-elasticsearch@d6f0b4b503
* SQL: fix name of Arithmetic functions
Remove id from name of Arithmetic function and improve name of Neg
Original commit: elastic/x-pack-elasticsearch@4f3e8d6a2d
Since elastic/x-pack-elasticsearch#3254 security headers have been stored in datafeed cluster state
to allow the datafeed to run searches using the credentials of the user
who created/updated it. As a result the parser was changed to read the
"headers" field so that cluster state could be reloaded. However, this
meant that datafeed configs could be submitted with a "headers" field.
No security loophole arose from this, as subsequent code overwrites the
contents of any supplied headers. But it could be confusing that an
erroneously supplied field did not cause a parse failure as it usually
would.
This change makes the config parser for datafeeds reject a "headers"
field. Now only the metadata parser used for reloading cluster state
will read a "headers" field.
Original commit: elastic/x-pack-elasticsearch@afa503275f
java.time features it's own halted clock, called a fixed clock, we can
use that one.
On top of that the watcher xcontent parser does not need a clock at all,
just a timestamp when parsing happened.
Original commit: elastic/x-pack-elasticsearch@2061aeffe1
The api jar was added for xpack extensions. However, extensions have
been removed in favor of using SPI, and the individual xpack jars like
core and security are published to enable this. This commit removes the
api jar, and switches the transport client to use the core jar (which
the api jar was just a rename of).
Original commit: elastic/x-pack-elasticsearch@58e069e66c
There were a number of leftover unnecessary elements in the module
build.gradle files that were holdovers from copying the original plugin
build.gradle. This commit removes these elements.
Original commit: elastic/x-pack-elasticsearch@08babbd520
Calling start() when already in the STARTING state doesn't do anything, so the component
gets stuck in STARTING state forever.
Also: wait on the required index name not just the cluster.
Also: added more logging to help diagnose such issues (either in RemoteIndexAuditTrailStartingTests or production)
Original commit: elastic/x-pack-elasticsearch@fb81214fe7
The old home made sense before x-pack was split. The new home lines up
with where security keeps its scripts.
The jar file wasn't being included any more so this re-adds that.
Original commit: elastic/x-pack-elasticsearch@d3ec941397
This commit adds special handling for null values when building a DistinguishedNamePredicate for
role mapping. Previously this would have resulted in an exception from the unboundid ldapsdk as
the DN is invalid.
relates elastic/x-pack-elasticsearch#3787
Original commit: elastic/x-pack-elasticsearch@9386dae03e
This allows any datetime function to be present in `EXTRACT` which feels
more consistent. `EXTRACT(FOO FROM bar)` is now just sugar for
`FOO(bar)`. This is *much* simpler to explain in the documentation then
"these 10 fields are supported by extract and they are the same as this
subset of the datetime functions."
The implementation of this is a little simpler then the old way. Instead
of resolving the function in the parser we create an
`UnresolvedFunction` that looks *almost* just like what we'd create for
a single argument function and resolve the function in the `Analyzer`.
This feels like a net positive as it allows us to group `EXTRACT`
resolution failures with other function resolution failures.
This also creates `UnresolvedFunctionTests` and
`UnresolvedAttributeTests`. I had to create `UnresolvedFunctionTests`
because `UnreolvedFunction` now has three boolean parameters which is
incompatible with the generic `NodeSubclassTests`'s requirement that all
ctor parameters be unique. I created `UnresolvedAttributeTests` because
I didn't want `UnresolvedFunctionTests` to call `NodeSubclassTests` and
figured that we'd want `UnresolvedAttributeTest` eventually and now felt
like as good a time as any.
Added a
Original commit: elastic/x-pack-elasticsearch@358aada308
If any of the follow take place on security index, then any cached role mappings
are potentially invalid and the associated realms need to clear any cached users.
- Index recovers from red
- Index is deleted
- Index becomes out-of-date / not-out-of-date
Original commit: elastic/x-pack-elasticsearch@1bcd86fcd4
The HTTP Exporter in Monitoring allowed users to set a timeout parameters
for the requests. When set, this was setting the `master_timeout` query parameter
in Bulk Requests. The problem is that Bulk Requests do not support this type of
timeout.
Original commit: elastic/x-pack-elasticsearch@9be194006e
This adds support to allow different schemes in a proxy being used
compared to what the actual request requires. So if your proxy runs via
HTTP, but the endpoint you want to connect to uses HTTPS, this is now
possible to configure the proxy explicitely.
Also a small unit test for parsing this has been added.
relates elastic/x-pack-elasticsearch#3596
Original commit: elastic/x-pack-elasticsearch@176f7cdf0e
Tests have been failing because of out of order cluster state processing
or because of stopping/starting was still in progress. Current tests do
not do further stop/start tries after the first leading to potential
being stuck in an unwanted state. This commit removes the methods
checking for the state being started or stopped in favor of using the
stopWatcher/startWatcher methods which now check if the desired state is
reached and otherwise issue another start/stop command.
Original commit: elastic/x-pack-elasticsearch@97b3232a6a
