This parameter ceased to work when Elasticsearch 5 introduced strict
parameter handling, because of a missing test.
This commit adds the parameter to the rest handler responseParams()
and adds a test along with the needed YAML definition.
relates elastic/x-pack-elasticsearch#2396
Original commit: elastic/x-pack-elasticsearch@8638df336c
If the duration time was 0 (and this might happen due to
using System.currentTimeMillis), the is_true check
still returns false.
The correct fix will be done later to replace the offending
measurement calls and replace them. Then we can add back this
line.
Original commit: elastic/x-pack-elasticsearch@076a9a37cc
A bunch of integration tests should have been built as unit tests
or already have unit test equivalents.
This commit removes integration tests as well as adding REST equivalents
or creating unit tests instead of extending from AbstractWatcherIntegrationTestCase
Original commit: elastic/x-pack-elasticsearch@a97b99467d
This commit removes some extraneous trailing newlines from
keystore.bash, the packaging test cases for the interaction between
installing X-Pack and the keystore.
Original commit: elastic/x-pack-elasticsearch@86250ecfbc
* Don’t count incomplete buckets in data stream diagnostics
* Fix tests now bucket_count doesn’t include partial buckets
Original commit: elastic/x-pack-elasticsearch@bc1a7bd9e7
This commit adapts to the renaming of the TransportResyncReplicationAction in core and also adds
an assertion to the check for a user being present when sending a request. The assertion is added
so that we can hopefully catch these scenarios in our testing as the assertion error will cause the
node to die but the ISE will just be seen in the logs. Since we do not run with assertions enabled
in production, the ISE is left to handle those cases.
relates elastic/x-pack-elasticsearch#2335
Original commit: elastic/x-pack-elasticsearch@c5ce0c93af
In `mutateInstance()` the from or size could become negative if the other one was pushed over the limit for `from + size`. This change fixes this case to make sure after the mutate method is called the from and size obey the limit but are also both `>= 0`
relates elastic/x-pack-elasticsearch#2344
Original commit: elastic/x-pack-elasticsearch@a8a7072fcc
* Add reserved dashboards_only_user role
* Fix line too long
* add tests for new reserved role
* rename role, hopefully fix tests
* Fix test
Original commit: elastic/x-pack-elasticsearch@99f6718c7c
`authc.token.enabled` is true unless `http.ssl.enabled` is `false` and `http.enabled` is `true`.
* TokenService default enabled if HTTP_ENABLED == false
* Fixed tests that need TokenService explicitly enabled
* [DOC] Default value for `xpack.security.authc.token.enabled`
Original commit: elastic/x-pack-elasticsearch@bd154d16eb
* Moves more classes over to ToXContentObject/Fragment
* Removes ToXContentToBytes
* Removes ToXContent from Enums
* review comment fix
* slight change to use XContantHelper
Original commit: elastic/x-pack-elasticsearch@0f2d3f328b
With Gradle 4.1 and newer JDK versions, we can finally invoke Gradle directly using a JDK9 JAVA_HOME without requiring a JDK8 to "bootstrap" the build. As the thirdPartyAudit task runs within the JVM that Gradle runs in, it needs to be adapted now to be JDK9 aware.
Relates to elastic/elasticsearch#25859
Original commit: elastic/x-pack-elasticsearch@4bf266e0b0
As there are two indices to upgrade for watcher, it makes a lot of sense
to also have two upgrade checks.
There is one upgrader for the watches index, which deletes
old templates, adds the new one before and then does the reindexing.
Same for the triggered watches index.
This also means, that there will be two entries popping up in the kibana
UI.
Note: Each upgrade check checks if the other index (for the .watches
upgrade check the triggered watches index and vice versa) is already
upgraded and only if that is true, watcher is restarted.
relates elastic/x-pack-elasticsearch#2238
Original commit: elastic/x-pack-elasticsearch@2c92040ed6
I noticed this while working on a previous issue with atomic move writer
(silent swallowing of exceptions). Namely, atomic move writer has
dangerous semantics. The problem is as follows: atomic move writer works
by writing lines to a temporary file, and then in its close method it
replaces the target path with the temporary file. However, the close
method is invoked whether or not all writes to the temporary file
succeeded (because writers obtained from atomic move writer are used in
try-with-resources blocks, as they should be). There is no way to
distinguish that the writer is being closed in a successful scenario
versus a failure scenario. In the close method for atomic move writer,
the target file is replaced by the temporary file. This means that the
target file is replaced whether or not writing to the temporary file
actually succeeded. Since these atomic move writers are used for user
configuration files (users and user_roles), a failure here can lead to
data loss for the user, a tragedy!
There is another (less serious) problem with the atomic move
writer. Since the close method tries to move the temporary file in place
of the existing file, the temporary file can be left behind if there is
another failure in the close method (e.g., closing the underlying file
after writing, or setting the permissions on the temporary file). This
means that in some situations, atomic move writer will leave temporary
files behind (which is not definitively not atomic).
This commit replaces the atomic move writer with a safer mechanism. We
still perform the write atomically in the following sense: we write to a
temporary file. Either writing to that file succeeds or it fails. If
writing succeeds, we replace the existing file with the temporary
file. If writing fails, we clean up the temporary file and the existing
file remains in place.
Relates elastic/x-pack-elasticsearch#2299
Original commit: elastic/x-pack-elasticsearch@3199decb0a
Certain types of datafeeds cannot have null chunking configs, so
setting chunking config to null sometimes doesn't stick as null
Original commit: elastic/x-pack-elasticsearch@3a52bad460
When a watch is executed currently, it gets passed an in-memory
watch object, that was loaded, before the execution started.
This means there is a window of time, where an old watch could still
be executing, then a watch gets loaded for execution, then the old watch
execution finishes and updates the watch status and thus reindexes the
watch.
Now the watch, that got loaded for execution, executes and tries to
store its watch status, but fails, because the version of the watch
has changed.
This commit changes the point in time where the watch is loaded. Now
this only happens, while a watch is in its protected execution block,
and thus we can be sure, that there is no other execution of the watch
happening.
This will primarily impact watches, that execute often, but their
runtime is longer than the configured interval between executions.
Side fix: Removed some duplicate testing method and moved into
WatcherTestUtils, fixed a tests with a ton of if's with random booleans
into separate tests.
relates elastic/x-pack-elasticsearch#395
Original commit: elastic/x-pack-elasticsearch@bf393023d7
Today it's impossible to run xpack bwc tests against any other branch
or remote than upstream. This allows to pass `-Dtests.bwc.refspec` to
change the refspec to use for the bwc tests.
Original commit: elastic/x-pack-elasticsearch@4d365f5a6e
Alexander Reelsen
Hendrik Muhs
David Kyle
Dimitrios Athanasiou
Lisa Cawley
Jason Tedor
Ryan Ernst
debadair
Jim Ferenczi
Michael Basnight
Jay Modi
Colin Goodheart-Smithe
Christoph Büscher
Stacey Gammon
Albert Zaharovits
Yannick Welsch
David Roberts
Simon Willnauer