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

Allow defining index name/alias(es) on index upgrade #36390

Closed
DwayneNeri opened this issue May 9, 2019 · 5 comments
Closed

Allow defining index name/alias(es) on index upgrade #36390

DwayneNeri opened this issue May 9, 2019 · 5 comments
Labels
enhancement New value added to drive a business result Feature:Upgrade Assistant Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more

Comments

@DwayneNeri
Copy link

Describe the feature:

  • Allow a user to choose the destination index name during an index upgrade process.
  • Additionally, allow a user to override aliases created during the same process.

This seems to be purely cosmetic at this time. Administrators who have a very specific index naming system may be frustrated by the default values.

Describe a specific use case for the feature:
After, recently upgraded elasticsearch and kibana from 6.x to 7.0.1, I checked out the "8.0 Upgrade Assistant" from the Management section. It reported that my index was created with an older version, and suggested I reindex after a backup, which I performed.

Due to the need to change a field from auto-discovered integer to float, a relatively common problem newbies like me might encounter, I had already adopted a new naming convention and reindexed in the past. I chose the naming convention of indexname_vn, where n indicates the version. The intent is to have a base name always represented by an alias to indexname, with the underlying index able to increment revisions as needed.

During the process, the upgrade process flawlessly recreated my index, using aliases to ensure functionality. In this case, the default naming convention caused a break in my preferred convention. Instead of using indexname_v[n+1], as I would have preferred if I were able to make the decision myself, it created an index with name reindexed-v7-indexname_v2, with two aliases: indexname and indexname_v2.

The end state I would have preferred is to simply have indexname_v3 with a single alias, indexname. If I were able to select the destination index name, and perhaps alias names as well, the end state would have been cleaner.

@nreese nreese added Feature:Data Views Data Views code and UI - index patterns before 8.0 enhancement New value added to drive a business result Feature:Upgrade Assistant Team:Operations Team label for Operations Team labels May 9, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-operations

@tylersmalley tylersmalley added Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more and removed Team:Operations Team label for Operations Team labels May 9, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/es-ui

@tylersmalley
Copy link
Contributor

I believe there is already an issue open for the re-index wizard, but I can't seem to find it.

@cjcenizal
Copy link
Contributor

There are a couple: #8110 and #24708.

@cjcenizal cjcenizal removed the Feature:Data Views Data Views code and UI - index patterns before 8.0 label May 29, 2019
@jloleysens jloleysens moved this from To do to To do (features) in Upgrade Assistant (UA) Upgrades Feb 21, 2020
@alisonelizabeth
Copy link
Contributor

I'm going to close this for now since we do not have plans to support this for the 7-8 upgrade in Upgrade Assistant. The reindex wizard work can be tracked via #46755.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New value added to drive a business result Feature:Upgrade Assistant Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more
Projects
Development

No branches or pull requests

6 participants