Skip to content

Conversation

@thecoop
Copy link
Member

@thecoop thecoop commented Oct 31, 2025

No description provided.

@thecoop thecoop force-pushed the int-hnsw-bfloat16-enabled branch from fc22aa4 to 30fb01b Compare October 31, 2025 15:16
@thecoop thecoop force-pushed the int-hnsw-bfloat16-enabled branch from 30fb01b to 2cf09b7 Compare October 31, 2025 15:25
@thecoop
Copy link
Member Author

thecoop commented Oct 31, 2025

Using the new quantizer has changed query behaviour, requiring some investigation

elasticsearchmachine and others added 24 commits November 3, 2025 12:21
…astic#137023)

Following elastic#136813, we expose to data stream lifecycle the new sampling method config in the downsampling API. This will allow users to configure the sampling method directly in the lifecycle configuration. For example:
```
PUT _data_stream/my-ds/_lifecycle
{
  "data_retention": "10d",
  "downsampling_method": "last_value",
  "downsampling": [
     {
       "after": "1d",
       "fixed_interval": "5m
     }
  ]
}
```
As of elastic#133954, we clone indices before performing the force-merge step in the `searchable_snapshot` action. On slow CI servers, 10 seconds for the index to go through the whole `searchable_snapshot` action isn't enough, so we bump the timeout to 20 seconds.

I looked at the logs of a few test failures, and ILM was clearly still progressing when the test timed out. I didn't identify any particular step that was taking extraordinarily long; there were always just a few steps that took a bit longer. I would love to make these tests faster rather than bumping the timeout, but the `searchable_snapshot` action is simply one of the largest ILM actions and ILM itself isn't particularly fast.

That being said, if a timeout of 20 seconds proves to be insufficient (i.e. test failures come back), I do think it's worth having a look at reducing the runtime of the tests somehow first before we increase the timeout further.

Closes elastic#137149
Closes elastic#137151
Closes elastic#137152
Closes elastic#137153
Closes elastic#137156
Closes elastic#137166
Closes elastic#137167
Closes elastic#137192
…elastic#137520)

This reverts commit 4d3e27f. And then
re-applies the revert to
elastic#134738, so we only get an
effective revert of 
elastic#134511.
When Dataframes are disabled, do not try to call the Action and instead
assume there are no trained models associated with a dataframe job. This
avoids a transport exception for the disabled action.
This adds a new abstract method to MapperTestCase for checking whether
a particular field type configuration supports competitive iterators during
sorting.
…hat it was resolved to (elastic#136632)

* alexey-ivanov-es work

* iter

* field caps: local resolution working and tested

* CCS impl

* using CPS SAF resolution if present

* some TODOs to check later on

* [CI] Update transport version definitions

* iter

* iter

* iter

* iter

* Update docs/changelog/136632.yaml

* [CI] Auto commit changes from spotless

* iter

* iter

* iter

* iter

* only return resolved to if minTransportVersion supports it

* iter

* updated comment based on feedback

---------

Co-authored-by: elasticsearchmachine <[email protected]>
…lastic#137404)

In elastic#137139, ES819DocValuesFormat version will increment from 0 to 1. For bwc tests between version 0 and version 1, we need a copy of version 0. So copy the existing ES819TSDBDocValuesConsumer to ES819TSDBDocValuesConsumerVersion0 and add TestES819TSDBDocValuesFormatVersion0 which uses this consumer. Since ES819TSDBDocValuesConsumer and ES819TSDBDocValuesConsumerVersion0 are currently identical, this does not test anything yet, but will once elastic#137139 increments the version.
Mainly this is about removing the trappy implicit default master node
timeout in resize (shrink/split/clone) requests as per elastic#107984, but also
we drop the unnecessary `ActionType` subclass and the test-only
`ResizeRequestBuilder`, migrating the affected tests over to a new
`ResizeIndexTestUtils` instead. We also fix the order of index-name
arguments and make the `ResizeType` a mandatory parameter rather than
(trappily) defaulting to `SHRINK`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.