mirror of
https://github.com/elastic/kibana.git
synced 2025-06-27 18:51:07 -04:00
53173f1033
## Summary We recently got problems because some index creation settings are rejected by stateless ES, causing the whole system to fail and Kibana to terminate. We can't really use feature flags for this, given: 1. it doesn't really make sense to use manual flags for something that strictly depend on one of our dependency's capabilities 2. we're mixing the concept of "serverless" offering and "serverless" build. Atm we sometimes run "serverless" Kibana against traditional ES, meaning that the "serverless" info **cannot** be used to determine if we're connected against a default or serverless version of ES. This was something that was agreed a few weeks back, but never acted upon. ## Introducing ES capabilities This PR introduces the concept of elasticsearch "capabilities". Those capabilities are built exclusively from info coming from the ES cluster (and not by some config flag). This first implementation simply exposes a `serverless` flag, that is populated depending on the `build_flavor` field of the `info` API (`/` endpoint). The end goal would be to expose a real capabilities (e.g "what is supported") list instead. But ideally this would be provided by some ES API and not by us guessing what is supported depending on the build flavor, so for now, just exposing whether we're connected to a default of serverless ES will suffice. ### Using it to adapt some API calls during SO migration This PR also adapts the `createIndex` and `cloneIndex` migration action to use this information and change their request against ES accordingly (removing some index creation parameters that are not supported). --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| core-rendering-browser-internal | ||
| core-rendering-browser-mocks | ||
| core-rendering-server-internal | ||
| core-rendering-server-mocks | ||