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.

Sign up for GitHub

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

Jump to bottom

Improve UX when attempting to upgrade Kibana when ES is short on disk space #116616

Closed
stacey-gammon opened this issue Oct 28, 2021 · 8 comments
Closed

Improve UX when attempting to upgrade Kibana when ES is short on disk space #116616

stacey-gammon opened this issue Oct 28, 2021 · 8 comments
Labels
Feature:Migrations Feature:Upgrade Assistant impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more

Comments

@stacey-gammon
Copy link
Contributor

stacey-gammon commented Oct 28, 2021 •
edited by rudolf
Loading

If a user attempts to upgrade Kibana when ES disk space is close to the low disk watermark limit, the upgrade will fail, with no indication why, or how to resolve it. This is a poor user experience, especially in Cloud.

We should not only warn users ahead of time in Cloud if the upgrade will fail but see if we can improve the experience if they do so anyway.
@stacey-gammon stacey-gammon added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more labels Oct 28, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-stack-management (Team:Stack Management)

@exalate-issue-sync exalate-issue-sync bot added impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort labels Nov 1, 2021
@rudolf
Copy link
Contributor

rudolf commented Nov 3, 2021

To warn users before an upgrade cloud would have to call a Kibana API to ask it "are we good to upgrade". With upgrade assistant now being used in minor upgrades too, this API feels very similar to the upgrade assistant API that cloud already uses.

However, the upgrade assistant is currently described as "identifies deprecated settings in your configuration, enables you to see if you are using deprecated features" https://www.elastic.co/guide/en/kibana/current/upgrade-assistant.html So low disk space doesn't exactly fit into that definition.

@elastic/kibana-stack-management how do you feel about broadening the scope of upgrade assistant to surface any problems that might prevent a successful upgrade?

We would have to introduce a new deprecationType, best I can think of is deprecationType: 'environment' for anything in your environment that could prevent an upgrade but isn't a configuration option.

@cjcenizal
Copy link
Contributor

how do you feel about broadening the scope of upgrade assistant to surface any problems that might prevent a successful upgrade?

++ Agreed.

We would have to introduce a new deprecationType, best I can think of is deprecationType: 'environment' for anything in your environment that could prevent an upgrade but isn't a configuration option.

I think we should bring in a designer to figure out this UX and work backwards to implementation. It seems like users would find it surprising to see information in the deprecation issues tables that's not related to breaking changes.

One possibility is to expand Upgrade Assistant's information architecture to differentiate between "data" and "deployment" upgrade blockers. Deprecations would fall into the former and insufficient resources would be in the latter.

@exalate-issue-sync exalate-issue-sync bot added loe:medium Medium Level of Effort loe:small Small Level of Effort and removed loe:small Small Level of Effort loe:medium Medium Level of Effort labels Nov 4, 2021
@bojian-ben-li
Copy link
Member

I have two cases today hitting this scenario. Both are ESS deployments. Customer attempt upgrade then the ES node disk exceed 85% and new .kibana indices not able to be allocated and in red.

@mshustov
Copy link
Contributor

Agreed.

@cjcenizal Is the Stack Management team going to work on the problem? Can I remove team:Core label then?

@cjcenizal cjcenizal removed the Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc label Dec 15, 2021
@cjcenizal
Copy link
Contributor

@mshustov Done!

@pgayvallet pgayvallet mentioned this issue Mar 28, 2022
Closed
@alisonelizabeth
Copy link
Contributor

I believe this has been addressed already via elastic/elasticsearch#83544

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Feature:Migrations Feature:Upgrade Assistant impact:low Addressing this issue will have a low level of impact on the quality/strength of our product. loe:small Small Level of Effort Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@cjcenizal @rudolf @pgayvallet @mshustov @alisonelizabeth @yuliacech @elasticmachine @stacey-gammon @bojian-ben-li