This change makes the IndexLifecycleManager check for both index existence and up to date mappings
on the index prior to executing the provided runnable. Doing this provides a mechanism to make
non-breaking mapping updates to the security index in minor versions.
relates elastic/x-pack-elasticsearch#3462
Original commit: elastic/x-pack-elasticsearch@80f05d83b4
This commit adds both the security index template and the audit index template to the excluded
templates for the RemoteIndexAuditTrailStartingTests and IndexAuditTrailTests. By allowing the
templates to remain in place, we make it easier for subsequent tests in the suite to have their
audit trails started.
Relates elastic/x-pack-elasticsearch#435
Original commit: elastic/x-pack-elasticsearch@6e54de19f9
By moving tokenization for categorization to Java we give users access to considerably more options for tokenizing their log messages prior to using ML to categorize them. Now all Elasticsearch analyzer functionality is available, which opens up the possibility to sensibly categorize non-English log messages.
Relates elastic/machine-learning-cpp#491
Original commit: elastic/x-pack-elasticsearch@5d61b67614
In order to support buttons that can be clicked on within a slack
message, this commits adds support for so called actions within
attachments. This allows to create buttons, that are clicked and execute
a GET request, so actions must be idempotent according to the official
slack documentation.
Official slack documentation is available at
https://api.slack.com/docs/message-attachments#action_fields
Original commit: elastic/x-pack-elasticsearch@29ddc90b01
This commit introduces audit event filtering policies for the logging audit.
Until now the only way to temper the gush of audit events was to specifically
pick some event types that were reported.
This superposes a way (named policies) to filter events using lucene regexp filters on
the following event fields: users, realms, roles and indices. The policies are ignore
policies, ie when an event matches it is ignored (not reported).
Original commit: elastic/x-pack-elasticsearch@233f685121
This creates a cluster alert that triggers whenever a node is:
- Added
- Removed
- Restarted (aka Removed and Added between collections)
Unlike all previous cluster alerts, this cluster is always instantly resolved because there is no way to otherwise resolve it later (especially if nodes are replaced).
This will require a small change to the UI so that it does not simply ignore resolved alerts.
Original commit: elastic/x-pack-elasticsearch@6340bf7960
We need to push this flag down to the command line for BWC builds or the
artifacts in release tests will have the wrong version (being considered
snapshots instead of non-snapshots).
Original commit: elastic/x-pack-elasticsearch@279fd02aa7
This commit modifies the BWC build to invoke the Gradle wrapper. The
motivation for this is two-fold:
- BWC versions might be dependent on a different version of Gradle than
the current version of Gradle
- in a follow-up we are going to need to be able to set JAVA_HOME to a
different value than the current value of JAVA_HOME
Relates elastic/x-pack-elasticsearch#3502
Original commit: elastic/x-pack-elasticsearch@22062f635b
The HttpClient uses an Apache HTTP client class named StringEntity to
encode a HTTP request body. This one however assumes ISO-8859-1 as its
charset when encoding the string based body to bytes.
This commit switches to a byte array based body, then sets the content
type header and falls back to the old text/plain content type if no
content type header is specified.
relates elastic/x-pack-elasticsearch#3397
Original commit: elastic/x-pack-elasticsearch@d5a6e7f0c7
The categorization integration tests were picking up a bug in the C++
categorization code, but the expected results were set incorrectly to
match the incorrect C++ output. This change adjusts the expected
results to reflect what is really expected. It also mutes the tests
to avoid failures while the C++ fix propagates through the build
process. The tests will be unmuted tomorrow.
Relates elastic/machine-learning-cpp#512
Original commit: elastic/x-pack-elasticsearch@d2b57b6216
When creating a transport client for a remote index audit trail, we are
implicitly allowing the construction of this transport client to
initialize the number of processors that Netty thinks are on the
system. Since we never pushed down the number of processors, this will
always default to the number of cores on the machine. If the user has
also set the processors setting, when the server bootstraps it will try
to push the number of processors down to Netty too. If this value does
not match the number of cores, we will fail in bootstrap because we
guard against initializing the number of processors that Netty sees to
different values. Instead, the transport client should inherit the
number of processors too and push this down when it pushes the number of
processors down to Netty. We have to worry about another possibility: an
explicit setting for the number of processors for the transport client
so we require this matches the inherited value.
Relates elastic/x-pack-elasticsearch#3469
Original commit: elastic/x-pack-elasticsearch@032810bb0b
Minor refactoring on the reserved realm:
- Removed some duplicated code
- Added in some additional assertions
- Extended some testing
- Removed use of the obsolete "allow_default_passwords" from the test.
Original commit: elastic/x-pack-elasticsearch@584171d2bd
The BWC tests on 6.x need to test both 6.1 and 5.6, so the theory here
is that they just need more memories. This bumps it to ensure the tests
dont OOM.
This bumps it from the previous 1536m, which was already bumped from the
default of 1024m.
Original commit: elastic/x-pack-elasticsearch@cf5700ef47