This creates a basic skeleton for the plugin split by adding folders and example
`build.gradle` files. It also includes a non-implemented `migrate-plugins.sh`
script that we can fill in at a later time.
Relates to elastic/x-pack-elasticsearch#2925
Original commit: elastic/x-pack-elasticsearch@2ab035d6b6
Generate passwords from [A-Za-z0-9] so that they are safe to be
used in shell scripts.
Entropy deterioration is not significant (124.9 -> 119), generated
passwords still meet guidelines and best practices regarding length
and complexity.
Resolveselastic/x-pack-elasticsearch#3087
Original commit: elastic/x-pack-elasticsearch@078639e7c2
Hopefully fixes the Windows CI failures that break on cloning the repository into a target directory with a lengthy path name.
Original commit: elastic/x-pack-elasticsearch@fe18e95d3f
When using the security networking implementations, the Netty jars that
are in play are those that are loaded in the X-Pack classloader. This
means that permissions granted to the Netty jars loaded in the
transport-netty4 module classloader do nothing. Instead, we have to
grant the same permissions to the Netty jars in the X-Pack
classloader. This commit does this.
Relates elastic/x-pack-elasticsearch#3247
Original commit: elastic/x-pack-elasticsearch@91780597b9
* Tests: Replace YAML tests with ESTestRestCase to be able to wait for events
The YAML tests did not have any possibility to wait for the watches to
be created. A hard ten second timeout was used, that could not be
aborted, by simulating a sleep when waiting for a number of nodes that
never occured in the cluster.
This commit replaces those waiting YAML tests with ESRestTestCases, that
use `assertBusy()` to exit early once the watches have been added. Also
this increases the wait time if needed, as these tests tend to fail on
CI.
relates elastic/x-pack-elasticsearch#3217
Original commit: elastic/x-pack-elasticsearch@74b9945d88
* Add Special Event
* Add special events to update process
* Add time condition and skip rule actions.
* Update special events
* Address review comments
Original commit: elastic/x-pack-elasticsearch@80500ded76
This is mainly a promotion of Literal to Attribute to better handle folding expressions from extracted queries
Original commit: elastic/x-pack-elasticsearch@c3bb48bb61
Given that the Catalog was only ever used to hold a single index, the corresponding abstraction can be removed in favour of the abstraction that it holds, namely `GetIndexResult`.
Original commit: elastic/x-pack-elasticsearch@6932db642c
Given that we get now filtered mappings directly from the get index API (in case security is configured with FLS), we don't need the security filter nor the filtered catalog. That means we can remove the delayed action support also from AuthorizationService and rather make SQLAction a composite action like others. It will be authorized as an action, but its indices won't be checked while that will happen with its inner actions (get index and search) which need to be properly authorized.
Also, SQLGetIndicesAction is not needed anymore, as its purpose was to retrieve the indices access resolver put in the context by the security plugin for delayed actions, which are not supported anymore.
This commit kind of reverts elastic/x-pack-elasticsearch#2162, as it is now possible to integrate with security out-of-the-box
relates elastic/x-pack-elasticsearch#2934
Original commit: elastic/x-pack-elasticsearch@64d5044426
This PR uses a new extension point that's being added to Elasticsearch (see https://github.com/elastic/elasticsearch/pull/27603) so that the security plugin can filter the mappings fields returned by get index, get mappings, get field mappings and field capabilities API.
This effort aims at filtering information returned by API in the `indices/admin` category and field capabilities. It doesn't filter what the cluster state api returns as that is a cluster level operation.
One question is about backwards compatibility given that we would like to have this in 6.2. Shall we treat this as a bug as mappings should have been filtered before? Not sure if it's going to break existing integrations.
relates elastic/x-pack-elasticsearch#340
Original commit: elastic/x-pack-elasticsearch@d7e3fd3fa1
Before this was done it was easy to get into the situation where a
job created in 5.x with a default model memory limit of 4GB could not
be opened on any node in the cluster. Following this change this
problem will no longer occur for jobs that ran for a decent amount of
time on the old cluster.
relates elastic/x-pack-elasticsearch#3181
Original commit: elastic/x-pack-elasticsearch@cb029debba
* SQL: GROUP BY with multiple fields are forbidden
The check is performed in the folder Verifier as the optimizer can eliminate some fields (like those with constants)
Original commit: elastic/x-pack-elasticsearch@8d49f4ab02
SQL: Extend HAVING support
Enhance Analyzer to support HAVING scalar functions over aggregates
Enhance Analyzer to push down undeclared aggs into the Aggregate
Fix bug in Analyzer$MissingRef that caused invalid groupings to still be resolved when pushed into an Aggregate
Preserve location information across the plan
Add AttributeMap as a backing for AttributeSet
Add Optimizer rule for combining projects
Add tz to DT functions toString
Change formatTemplate to not use String.format and thus to avoid
interfering with special % chars
Extend dataset with random salary and languages
Add unit tests for AttributeMap
Fix MathFunction scripting
Improve MissingRefs to enrich UnresolvedAttribute with metadata
During the Analysis unpushed attributes are automatically enriched to
provide more accurate error information
Enhance Verifier to deal with invalid (but resolved) ORDER/HAVING
Add OrderBy arithmetic tests
Improve Verifier to prevent GROUP BY on aggregations
Add tests on grouping by scalar functions
Original commit: elastic/x-pack-elasticsearch@5030d7a755
This suite seems to be timing out on the CI slaves. Hopefully,
some extra time will stop the failures.
Original commit: elastic/x-pack-elasticsearch@95ba86be79
The watcher threadpool size was always five times the CPU core
count, resulting in a huge threadpool when with even 24 cores.
This changes the behaviour to be five times the number of cores
by default - as watcher is usually waiting on I/O you should have more
threads than cores, but it maxes out with 50 threads, unless the number
of available cores is higher than that.
relates elastic/x-pack-elasticsearch#3052
Original commit: elastic/x-pack-elasticsearch@eab5deb113
In order to support the source directory repo split, this commit
disables security for the regular integration tests.
The MonitoringSettingsFilterTests already existed as REST test, so
this test has been removed.
Relates elastic/x-pack-elasticsearch#2925
Original commit: elastic/x-pack-elasticsearch@519154dd5f
The pagerduty action allows to send contexts, which contains an array
of texts or images, each with a link.
The field of this data was named 'context' instead of 'contexts' and
thus those contects were never correctly parsed on the pagerduty side.
Unfortunately pagerduty accepts any JSON, thus this was not caught so
far.
This commit allows parsing of the old field name to retain BWC, but when
written out via toXContent, it will always use the 'contexts' field name.
relates elastic/x-pack-elasticsearch#3184
Original commit: elastic/x-pack-elasticsearch@50f0b65d56
* [DOCS] Refreshed ML screenshots
* [DOCS] Added screenshots for ML Data Visualizer
* [DOCS] Addressed feedback about data visualizer
* [DOCS] Fixed typo in ML tutorial
Original commit: elastic/x-pack-elasticsearch@2603536a93
This commit fixes the minimum value being smaller than the maximum value in a call to the
scaledRandomIntBetween, which causes the test to fail.
Original commit: elastic/x-pack-elasticsearch@da7d0ce0ce
When you click "delete" in the UI it force-deletes the datafeed then
force-deletes the job. For a datafeed doing lookback, this results
in a close followed very quickly by a kill on the autodetect process.
Depending on thread scheduling this could cause a lot of spurious
errors and exception traces to be logged.
This change prevents the log spam in this scenario.
relates elastic/x-pack-elasticsearch#3149
Original commit: elastic/x-pack-elasticsearch@091240f32a
Our rolling upgrade tests were failing on many machines due to using
the 5.x default of 4GB model_memory_limit, which then propagated forward
to 6.1+ even though the default is now lower.
Original commit: elastic/x-pack-elasticsearch@3b23d8fe9d