Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dev 240511 01 #108533

Closed
wants to merge 286 commits into from
Closed

Dev 240511 01 #108533

wants to merge 286 commits into from

Conversation

Zeri8
Copy link

@Zeri8 Zeri8 commented May 11, 2024

  • Have you signed the contributor license agreement?
  • Have you followed the contributor guidelines?
  • If submitting code, have you built your formula locally prior to submission with gradle check?
  • If submitting code, is your pull request against main? Unless there is a good reason otherwise, we prefer pull requests against main and will backport as needed.
  • If submitting code, have you checked that your submission is for an OS and architecture that we support?
  • If you are submitting this code for a class then read our policy for that.

brianseeders and others added 30 commits February 23, 2024 12:19
… index is assigned (elastic#105725) (elastic#105793)

ILM transitions to `wait-for-index-color` (a step that needs a cluster
state changed event to evaluate against) but misses the cluster state
event that notifies that `partial-index` is now `GREEN`. And then the
cluster is quiet and no more state changes occur and we timeout. Note
that the test is unblocked by the teardown of the IT that triggers some
cluster state changes.

This fixes the test by issueing some empty `reroute` request to cause
some cluster state  traffic in the cluster and ILM notices an index is
assigned.

Note that a production cluster is busy and ILM would eventually notice
the new state and make progress.

```
2024-02-22T06:33:01,388][INFO ][o.e.x.i.IndexLifecycleTransition] [node_t0] moving
index [index] from [{"phase":"frozen","action":"searchable_snapshot","name":"mount-snapshot"}] to [{"phase":"froz
en","action":"searchable_snapshot","name":"wait-for-index-color"}] in policy [policy]
[2024-02-22T06:33:01,490][INFO ][o.e.c.r.a.AllocationService] [node_t0] current.health="GREEN"
message="Cluster health status changed from [YELLOW] to [GREEN] (reason: [shards started
[[partial-index][0]]])." previous.health="YELLOW" reason="shards started [[partial-index][0]]"
```

Fixes elastic#102405
…lastic#105593) (elastic#105800)

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
…#105650) (elastic#105808)

* ESQL: Fix wrong attribute shadowing in pushdown rules (elastic#105650)

Fix elastic#105434

Fixes accidental shadowing when pushing down `GROK`/`DISSECT`, `EVAL` or
`ENRICH` past a `SORT`.

Example for how this works:

```
...
| SORT x
| EVAL x = y
...

pushing this down just like that would be incorrect as x is used in the SORT, so we turn this essentially into

...
| EVAL $$x = x
| EVAL x = y
| SORT $$x
| DROP $$x
...
```

The same logic is applied to `GROK`/`DISSECT` and `ENRICH`.

This allows to re-enable the dependency checker (after fixing a small
bug in it when handling `ENRICH`).

* Make OptimizerRules compile again
…105842) (elastic#105846)

The build handles platform specific code which may be for arm or x86.
Yet there are multiple ways to describe 64bit x86, and the build
converts between the two in several places. This commit consolidates on
the x64 nomenclature in most places, except where necessary (eg ML still
uses x86_64).

relates elastic#105715
We only had a few mentions of 429 handling, now documenting our expectation generically.

Co-authored-by: David Turner <david.turner@elastic.co>
Co-authored-by: Liam Thompson <32779855+leemthompo@users.noreply.github.com>
…tic#105848) (elastic#105883)

The heap attack tests hit OOM where the circuit breaker was 
under-accounted. This was because the ProjectOperator retained
references to released blocks. Consequently, the released block couldn't
be GCed although we have decreased memory usage in the circuit breaker.

Relates elastic#10563
…5772) (elastic#105897)

We seem to have a couple of checks to make sure we delete the data
stream when the last index reaches the delete step however, these checks
seem a bit contradictory.

Namely, the first check makes use if `Index` equality (UUID included)
and the second just checks the index name. So if a data stream with just
one index (the write index) is restored from snapshot (different UUID)
we would've failed the first index equality check and go through the
second check `dataStream.getWriteIndex().getName().equals(indexName)`
and fail the delete step (in a non-retryable way :( ) because we don't
want to delete the write index of a data stream (but we really do if the
data stream has only one index)

This PR makes 2 changes: 1. use the index name equality everywhere in
the step (we already looked up the index abstraction and the parent data
stream, so we know for sure the managed index is part of the data
stream) 2. do not throw exception when we got here via a write index
that is NOT the last index in the data stream but report the exception
so we keep retrying this step (i.e. this enables our users to simply
execute a manual rollover and the index is deleted by ILM eventually on
retry)
) (elastic#105903)

First check whether the full cluster supports a specific indicator (feature) before we mark an indicator as "unknown" when (meta) data is missing from the cluster state.
* Update README.asciidoc

updating the readme with the latest blurb from PMM and a reference to RAG + a few links to search labs content.

* Tweak verbiage

---------

Co-authored-by: Liam Thompson <32779855+leemthompo@users.noreply.github.com>
(cherry picked from commit 0b664dd)

Co-authored-by: Serena Chou <serenachou@users.noreply.github.com>
…stic#105904) (elastic#105915)

Co-authored-by: Jonathan Buttner <56361221+jonathan-buttner@users.noreply.github.com>
…05929)

The health report API changed names in
elastic#92879, which causes this
YAML REST test to fail in versions < 8.7.0.

Closes elastic#105923
The GeoIP endpoint does not use the xpack http client. The GeoIP downloader uses the JDKs builtin cacerts.

If customer is using custom https endpoint they need to provide the cacert in the jdk, whether our jdk bundled in or their jdk. Otherwise they will see something like
```
...PKiX path building failed: sun.security.provier.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target...
```

(cherry picked from commit 30828a5)

Co-authored-by: Jennie Soria <predogma@users.noreply.github.com>
…stic#105995)

* ESQL: fix single valued query tests (elastic#105986)

In some cases the tests for our lucene query that makes sure a field is
single-valued was asserting incorrect things about the stats that come
from the query. That was failing the test from time to time. This fixes
the assertion in those cases.

Closes elastic#105918

* ESQL: Reenable svq tests

We fixed the test failure in elastic#105986 but this snuck in.

Closes elastic#105952
…5930) (elastic#105983)

This change ensures that the matches implementation of the `SourceConfirmedTextQuery` only checks the current document instead of calling advance on the two phase iterator. The latter tries to find the first doc that matches the query instead of restricting the search to the current doc. This can lead to abnormally slow highlighting if the query is very restrictive and the highlight is done on a non-matching document.

Closes elastic#103298
stefnestor and others added 20 commits May 3, 2024 03:35
…gram aggregation (elastic#108184)

 elastic#105359. we changed the bucket ordering for partial reduces which causes issues when the output is shared with a 
node running on an older version. This commit reorders the output to the expected order for previous versions.
…lastic#108282)

Currently, loading ordinals multiple times (after advanceExact) for 
documents with values spread across multiple blocks in the TSDB codec
will fail due to the absence of re-seeking for the ordinals block.

Doc-values of a document can spread across multiple blocks in two cases:
when it has more than 128 values or when it exceeds the remaining space
in the current block.
…) (elastic#108299)

This PR moves the doPrivileged wrapper closer to the actual deletion
request to ensure the necesary security context is established at all
times. Also added a new repository setting to configure max size for s3
deleteObjects request.

Fixes: elastic#108049
(cherry picked from commit bcf4297)

# Conflicts:
#	docs/reference/snapshot-restore/repository-s3.asciidoc
#	modules/repository-s3/src/main/java/org/elasticsearch/repositories/s3/S3BlobStore.java
Adjust the lower bound to include the case where the number of positions is zero.

Closes elastic#107847
The DirectEncoder currently returns the incorrect value for the
positionCount() method, which should be the number of positions ready in
the current batch. We need to keep track of whether a position is loaded
via encodeNextBatch() and consumed via the read() method. However, we
can always return 1 for positionCount(), indicating that one position is
already loaded. Our tests failed to catch this because mv_ordering
wasn't enabled when generating test blocks, effectively disabling the
DirectEncoders.

Closes elastic#108268
…lastic#108365) (elastic#108400)

(cherry picked from commit 4d9c2df)

# Conflicts:
#	x-pack/plugin/ent-search/src/main/java/org/elasticsearch/xpack/application/connector/syncjob/ConnectorSyncJobIndexService.java
…c#108393) (elastic#108420)

# Conflicts:
#	qa/rolling-upgrade/src/javaRestTest/java/org/elasticsearch/upgrades/DownsampleIT.java
#	qa/rolling-upgrade/src/javaRestTest/java/org/elasticsearch/upgrades/HealthNodeUpgradeIT.java
#	qa/rolling-upgrade/src/javaRestTest/java/org/elasticsearch/upgrades/IgnoredMetaFieldRollingUpgradeIT.java
#	qa/rolling-upgrade/src/javaRestTest/java/org/elasticsearch/upgrades/ParameterizedRollingUpgradeTestCase.java
#	qa/rolling-upgrade/src/javaRestTest/java/org/elasticsearch/upgrades/VectorSearchIT.java
#	x-pack/plugin/inference/qa/rolling-upgrade/src/javaRestTest/java/org/elasticsearch/xpack/application/InferenceUpgradeTestCase.java
…7485) (elastic#108436)

One user reached out mentioning that it would be a good idea to remind
users to re-upload the license after full cluster recovery from snapshot
as one can easily miss this when trying to figure out why some features
aren't working after the restore.

(cherry picked from commit 295fba3)

Co-authored-by: Rafi Estrada <62263912+TheRiffRafi@users.noreply.github.com>
…ic#108479)

The word `cannot` implies Elasticsearch prevents you from doing these
things, but it doesn't have this protection today (see elastic#73947). This
commit clarifies this by saying `must not` instead.

Closes elastic#108450
@Zeri8 Zeri8 requested review from a team as code owners May 11, 2024 02:39
Copy link

Documentation preview:

Copy link

❌ Author of the following commits did not sign a Contributor Agreement:
, 21df8b9

Please, read and sign the above mentioned agreement if you want to contribute to this project

@elasticsearchmachine
Copy link
Collaborator

@Zeri8 please enable the option "Allow edits and access to secrets by maintainers" on your PR. For more information, see the documentation.

@elasticsearchmachine elasticsearchmachine added v8.15.0 needs:triage Requires assignment of a team area label external-contributor Pull request authored by a developer outside the Elasticsearch team labels May 11, 2024
@Zeri8 Zeri8 closed this May 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external-contributor Pull request authored by a developer outside the Elasticsearch team needs:triage Requires assignment of a team area label v8.15.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet