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
* SQL: Move shared REST client methods to shared-client
This commit is a preliminary step for moving JDBC to the REST client. It extracts the common REST clients from CLI and moves it to shared-client. This will allow us to move to the 5 project setup: rest-proto, shared-client, server, jdbc, cli with the following dependencies:
server <-- rest-proto
shared-client <-- rest-proto
jdbc <-- shared-client
cli <-- shared-client
Relates to elastic/x-pack-elasticsearch#3419
Original commit: elastic/x-pack-elasticsearch@2e6a134de0
It is unsafe to clear passwords of bind requests if the connection is live
and might be used latter (for eg for group searches). This is a temporary
fix that exposes passwords in memory.
Original commit: elastic/x-pack-elasticsearch@e2e1f1a358
This commit hacks up the xpack repo in such a way that it moves all
actions that the transport client uses to plugin core. It also moves
any classes that those actions use to plugin core, with a few
exceptions. I tried to split up any classes that pulled in server side
logic into the client, but that was not always 100% possible. Consider
this commit a guide, and since I do not know the codebase for each
plugin, consider it a best guess for what should be moved. A few other
things were merged in below.
This commit extracts the parts of Condition and AlwaysCondition that are
needed by classes that will be moved into the client package. The only
odd thing here is that since there are two parent classes (Condition and
AlwaysCondition) it was not possible to make AlwaysConditionInteral
extend from AlwaysCondition and still parse a ConditionInternal object,
which is what the ConditionFactory expects.
This commit removes the use of internal users in the User class, and
instead moves them to Authentication, where they are used.
[insert obligatory chuck norris karate image here]
ref elastic/x-pack-elasticsearch#2925
Original commit: elastic/x-pack-elasticsearch@42d0b72209
This adds a traditional blacklist that can be set [dynamically] at the exporter level to block specific cluster alerts (watches) from being created. It goes further and actually removes any watch that has been created already for the current cluster.
Original commit: elastic/x-pack-elasticsearch@1f67bb9501
This modifies the default template to use auto_expand_replicas so that a one node cluster can stay green, even while using the Logstash management feature.
Original commit: elastic/x-pack-elasticsearch@b1ddf3af6f
In the previous pass, only the ".watch*" templates were impacted. This also should use `auto_expand_replicas`.
Original commit: elastic/x-pack-elasticsearch@5d3a4f1f7b
This creates all ML templates using the `index.auto_expand_replicas` set as `"0-1"` so that a single node cluster (e.g., dev) can startup as green.
Original commit: elastic/x-pack-elasticsearch@7a243c5b06
* Calendar event actions
* Add page params and date range tests
* Address review comments
* Support POSTing params in the body of a request
Original commit: elastic/x-pack-elasticsearch@22a7e17a8f
The test uses the bound address to determine how to speak to the node via http.
It currently takes the port but hard codes the host to `localhost`. This can lead
to mismatches where a port for ipv6 is used but localhost resolves to ipv4
relates elastic/x-pack-elasticsearch#3382
Original commit: elastic/x-pack-elasticsearch@e97363a521
This test is failing for days, possibly due to a change in core
Elasticsearch. This commit marks this test as awaits fix.
Original commit: elastic/x-pack-elasticsearch@8ed3965795
This test is failing for days, possibly due to a change in core
Elasticsearch. This commit marks this test as awaits fix.
Original commit: elastic/x-pack-elasticsearch@8d7db1c423
This test is failing for days, possibly due to a change in core
Elasticsearch. This commit marks this test as awaits fix.
Original commit: elastic/x-pack-elasticsearch@f519c2a7ee
