* Descriptive logs with docLinks for cluster shard limit exceeded
* Integration test for isClusterShardLimitExceeded
* Fix jest test snapshots
* Apply suggestions from code review
Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com>
* PR feedback
* PR feedback
* Unit tests for isClusterShardLimitExceeded
* Use constast for repeated strings
Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com>
* Add reproducing test case
* Fix and add integration test
* Transient settings should take preference
* Rename unsupported_cluster_routing_allocation error to incompatible_cluster_routing_allocation
* Retry INIT when action fails with [incompatible_cluster_routing_allocation]
* Apply suggestions from code review
Co-authored-by: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co>
* Fix archive with trial licence and re-enable skipped test
* Integration test for incompatible cluster routing allocation
* Fix types after renaming UnsupportedClusterRoutingAllocation
* Attempt to fix open handle tests
Co-authored-by: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co>
* reapply docs and doclink changes
* Updates wait_for_index_yellow_status response type on response timeout, updates create_index action and model to account for the changes
* Refactors clone_index action to account for new return type of waitForIndexYellow, updates model
* Updates README
* Updates snapshot
* Updates docs
* Fix import violations
* imports
* Extends the retry log message with an actionable item linking to the docs on every retryable migration action
* Refactor retry_state and model to allow linking to specific subsections in the docs
* Updates resolving saved objects migration failures docs
* Calls waitForIndexStatusYellow directly in actions integration tests
* Deletes comment
* Update src/core/server/saved_objects/migrations/model/retry_state.test.ts
Co-authored-by: Rudolf Meijering <skaapgif@gmail.com>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Rudolf Meijering <skaapgif@gmail.com>
With https://github.com/elastic/elasticsearch/pull/79081, we now cover Kibana's **Snapshot and Restore** feature in the Elasticsearch docs. This removes and redirects the related docs from Kibana.
It also updates some references to the `.kibana` system indices to include the `kibana` feature state. The `kibana` feature state is now the preferred way to back up and restore system indices and other configuration data for Kibana.
Relates to https://github.com/elastic/elasticsearch/issues/79675
* Migrations v2 docs
* Not all kibana distributions automatically restarted a killed process
* Mention that we add a write block to the outdated index
* Formating: collapse three notes into a single note with three bullet points
* Update docs/setup/upgrade/upgrade-standard.asciidoc
Co-authored-by: Josh Dover <1813008+joshdover@users.noreply.github.com>
* Add table of outdated / upgraded indices per version of Kibana
* Review feedback: separate section for multi-instance upgrade migrations
* Review feedback: link to saved objects management
* Review feedback: stronger wording for not deleting any indices
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Josh Dover <1813008+joshdover@users.noreply.github.com>
* Resolving failed Kibana upgrade migrations
* Move warning against rolling upgrades into upgrade-standard and call out stopping all instances in specific upgrade steps
* Add preventing migration failures section
* Add incompatible xpack.tasks.index: .tasks setting to preventing migration failures
* Fix link
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Add a note about index migrations to the kibana setup docs
* Tewak the migrations asciidocs for clarity
* docs: refine saved object migration details
Breaking down the migration process into sections helps people find
and link to relevant information more easily.
The focus is on ongoing maintenance of Kibana, whereas the initial new
experience in 6.5.0 is treated as a note of clarification.
Error handling should be expanded in the future to include details about
specific known error cases.
These changes include all three known upgrade scenarios:
1. New installation (K3 -> K5)
2. Standard upgrade (K4.2 -> K5)
3. Standard upgrade with reindex (K4.1 -> K5)
