Rollup was using a historical `rollup` doc type, when we should be using
`_doc` so that it is forward-compatible with the removal in 8.0
Original commit: elastic/x-pack-elasticsearch@4b3188e6c8
This is required so the Logstash Centralized Configuration Management UI in Kibana may make the GET / request to Elasticsearch and retrieve the cluster UUID. It then uses this cluster UUID to make a call to a Kibana Monitoring API to retrieve a list of pipelines from Monitoring. In order for the Kibana Monitoring API request to succeed, the logged-in user needs to have the built-in monitoring_user role anyway, so we give this role the cluster:monitor/main privilege.
Original commit: elastic/x-pack-elasticsearch@bf6ad5c1df
This changes the behaviour of AbstractWatcherIntegrationTestCase and its
startWatcher/stopWatcher methods. Instead of checking for the target
state and just starting or stopping if it does not match, the methods
now wait for certain states to be reached before starting or stopping.
This will fix test failures where a failure is started instead of
stopped or vice versa.
Original commit: elastic/x-pack-elasticsearch@f0b0954803
Fix bug in checking whether the expression properties has been
modified or not.
Change test to move from SIN to SQRT (as the former seem to return
different values (extra digit) across JDK versions - 8 vs 10)
Fixelastic/x-pack-elasticsearch#4335
Original commit: elastic/x-pack-elasticsearch@8f672c455d
In the ClusterPrivilegeTests class, the code was resetting the node
after each test and failures were seen in CI that were HTTP 401 when
a 403 was expected. This commit removes the resetting of the node
between tests as this was not necessary.
Additionally, there is an issue in the SecuritySingleNodeTestCase where
the rest client was not torn down afterstopping a node and starting a
new node. This means the client used in other tests would not be
connected to the right cluster. This change resolves this by tearing
down the rest client after the old node is torn down.
relates elastic/x-pack-elasticsearch#4383
Original commit: elastic/x-pack-elasticsearch@2f81a4b2e2
Currently there is a hardcoded check against 10000, which
is the default value of the max_result_window setting. This
is a relic of the past. Removing this hardcoded validation
means we respect the setting so that a user may alter it
when appropriate.
relates elastic/x-pack-elasticsearch#3672
Original commit: elastic/x-pack-elasticsearch@9c9c5bab89
- Changes in build SAML SP metadata to support multiple
encryption keys.
- Changes in Saml metadata command to support the use of
protected keystores.
- Changes to export and set proper usage type in key
descriptors of SP saml metadata XML.
- Changes in SAML realm to create chaining key info
credential resolver backed by Collection of encryption
keys as per SP configuration.
- Unit tests and test enhancements
relates elastic/x-pack-elasticsearch#3980,elastic/x-pack-elasticsearch#4293
Original commit: elastic/x-pack-elasticsearch@e02ebcc9e6
Some build tasks require older JDKs. For example, the BWC build tasks
for older versions of Elasticsearch require older JDKs. It is onerous to
require these be configured when merely compiling Elasticsearch, the
requirement that they be strictly set to appropriate values should only
be enforced if these tasks are going to be executed. To address this, we
lazy configure these tasks.
Original commit: elastic/x-pack-elasticsearch@804a11c243
This commit sets the BWC builds to use the version of the JDK that is
appropriate for the indvidual version of Elasticsearch under test.
Original commit: elastic/x-pack-elasticsearch@967a497a20
SYS TYPE returns an integer instead of a boolean (the bug was caused
by reading the ODBC spec which refers to the wire representation instead
of the JDBC one which uses primitives)
Original commit: elastic/x-pack-elasticsearch@f9fe64ab0d
Improve grammar to allow use of ? as an alternative to STRING
through-out all commands
Add various parsing tests checking the ? usage for SYS commands
Original commit: elastic/x-pack-elasticsearch@d0d1feeb4c
The IndexPrivilegeTests have been notoriously slow for years.
@polyfractal identified the primary issue, which is that these tests
were running against an internal cluster with 1 or 2 data nodes and had
the number of replicas set to 1 for indices by default and the methods
in the test would perform a wait for green. This wait for green would
take the full thirty seconds when there was a single data node as the
index could never reach green health due to an unassigned replica. This
could have been caught earlier by asserting the request did not timeout
but this assertion was not present.
This change does a few things to address the issues above. The first is
that these tests now extend SecuritySingleNodeTestCase, which is a new
class that extends ESSingleNodeTestCase and contains the necessary
logic for the setup and teardown of security; much of which is based
off of SecurityIntegTestCase. This means that these tests always run
against a single node cluster and have a much simpler setup. The
default index template for these tests applies settings so that indices
are created with a single shard and no replicas.
Assertions have been added to ensure the health checks with a wait for
green status have not timed out. A handcoded wait for snapshots to
finish has been replaced with an assertBusy call. Finally, the BadApple
annotation has been removed from the test.
Relates elastic/x-pack-elasticsearch#324
Original commit: elastic/x-pack-elasticsearch@572919273d
This changes JDBC so it can be released. It bundles the
`sql-shared-client` and `sql-proto` jars into the jar for the jdbc client.
It also Generates a pom for the jdbc driver when you run `gradle assemble`
on it. This will allow us to release the jdbc driver.
It also adds a zip distribution of the jdbc driver with all of its
dependencies bundled in the zip. It'd be nice to bundle all of the jdbc
driver's dependencies in the jar but we can't quite do that yet. So, for
now, to help folks using BI tools use the JDBC driver, we build a zip.
Original commit: elastic/x-pack-elasticsearch@9c668231d4
Rewrote the GROUP BY to use composite aggregation instead of terms
(and everything that comes with it) but instead rely on composite aggregation
This not only works better but simplifies the code complexity since
composite is a straight, two-level tree:
1. root/group-by/composite-keys
2. (metric) aggregations
This removes a lot of complexity from all stages that involve creating,
assembling and especially parsing the results.
By moving to composite agg, the aggregation/GROUP BY are now pageable
so the consumer/listener had to be extended to include a dedicated
cursor and specific (bucket) extractors inline with the scroll requests.
While at it, also improved the support for implicit GROUP BY by
formalizing it (previously it supported only counts and no other
agg).
In addition:
Fixed a JDBC bug that caused incorrect timeout to be passed
Improved the returned RowSet a bit and add better naming
Pick up @Nullable move from core
Make sure to specify the TimeZone for DateTimeHistogram extraction
Add missing javadoc
To avoid delegating NamedWriteableRegistry (NWR) and to keep the scope
clean, SQL writeables now handle their own serialization, keeping the
boundary between the Elasticsearch's NWR in place.
Pass NamedWriteableRegistry only when looking at the next page
To keep in line with the existing patter and simplify the code
bureaucracy, the deserialization happens directly.
Since the SearchSourceBuilder deserialization happens explicitly (and
it's otherwise opaque), the declarative invocation isn't necessary
anymore.
Add a bit more randomization in tests
Original commit: elastic/x-pack-elasticsearch@f5af046386
This commit switches the manual creation and addition of files to the
keystore to use the built-in support available in the integTestCluster
configuration closure.
This change removes the need to worry about the creation of the
keystore and possibly dealing with a prompt from the creation command.
Original commit: elastic/x-pack-elasticsearch@8a4026a096
Currently numDocs() is computed lazily, but this doesn't help since
BaseCompositeReader calls numDocs() on its sub readers eagerly. This may cause
performance issues since every time we wrap a reader with DocumentSubSetReader
(which means for every query when DLS is enabled) we need to recompute the
number of live documents, which runs in linear time with the number of matches
of the role query.
Not computing numDocs() eagerly in DocumentSubSetReader might help, but it
would also be fragile since callers of this method still usually assume that
it runs in constant time. So I am proposing that we add a cache of the number
of live docs in order to decrease the performance hit of document-level
security. I would expect this cache to be efficient as it will not only reuse
entries in-between refreshes, but also across refreshes for segments that
haven't received any new updates.
Original commit: elastic/x-pack-elasticsearch@5a3af1b174
Renaming should hopefully make it more clear that this is the size
of pages to process during rolling up, nothing to do with the size
of the various groups, metrics, etc.
Original commit: elastic/x-pack-elasticsearch@8a0a44f04b
This constructor was actually never used, other than in tests, and even then,
there is no need for a custom period type as the human-readable toString value
will suffice.
Original commit: elastic/x-pack-elasticsearch@fc666a04b9
It is common for users to wish to adjust the verification_mode in SSL
settings, usually with the intention of skipping hostname
verification. This has been supported for a long time, but the
relevant configuration setting was not clearly documented, which would
sometimes lead users to set `verification_mode` to `none`, and disable
more checks than they intended.
This commit adds clearer documentation regarding the options available
for `verification_mode` and actively discourages the use of `none`.
Original commit: elastic/x-pack-elasticsearch@2fdf53b42f
For the user cache, the crypt option rounds are actually the log2 of the number
of rounds. This commits updates the documentation to reflect this.
Original commit: elastic/x-pack-elasticsearch@d3cc2b7f29
With the change of requiring to configure account settings properly by
using affix settings, we forgot another special snowflake, namely the
configuration of mail properties, which can be arbitrary in the
configuration. Those properties are used when an email is sent.
This commit adds a few (but not all of those) options back and removes
the link in the documentation to refer to all of those settings.
Some settings are useless, as they only change the execution
expectations when a mail is sent, which the watch has control over.
The following settings are supported
* smtp.{host,port,user,password}
* smtp.auth
* smtp.starttls.{enable,required}
* smtp.{timeout,connection_timeout,write_timeout}
* smtp.{local_address,local_port}
* smtp.send_partial
* smtp.wait_on_quit
relates elastic/x-pack-elasticsearch#4048
Original commit: elastic/x-pack-elasticsearch@39d5624710
Adds `value_count` as one of the accepted metrics. The caveat is that
it only accepts numeric values for two reasons:
- Job validation at creation makes sure all metrics are numeric fields.
Changing this would require new syntax (or disallowing anything but
value_count on mixed fields)
- when `toBuilders()` is called, we have to supply a ValueSource to
the ValueCountBuilder, and we don't know what the field type is at that
time.
These are both fixable, but relatively more involved. I think numeric-only
is a reasonable limitation to start with
Original commit: elastic/x-pack-elasticsearch@270f24c8bf
Add a check to the migration assistant to warn about the renaming of
`delimited_payload_filter` to `delimited_payload`. This should still
word for old indices from 7.0 on but will throw an error for newly
created indices and the user should be warned about it when running the
migration checks.
Original commit: elastic/x-pack-elasticsearch@5d55e4e499