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
Closed
Dev 240511 01 #108533
+16,725
−9,001
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…re uploaded (elastic#105530) (elastic#105784) (cherry picked from commit e568f70)
… 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>
test mute for elastic#105952
…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
…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.
Backport of elastic#107862 to 8.13
…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.
Changed "that JVM" to "the JVM"
…) (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
Documentation preview: |
❌ Author of the following commits did not sign a Contributor Agreement: Please, read and sign the above mentioned agreement if you want to contribute to this project |
@Zeri8 please enable the option "Allow edits and access to secrets by maintainers" on your PR. For more information, see the documentation. |
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
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
gradle check
?