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

ILM data allocation UX in Cloud #79946

Closed
cjcenizal opened this issue Oct 7, 2020 · 4 comments
Closed

ILM data allocation UX in Cloud #79946

cjcenizal opened this issue Oct 7, 2020 · 4 comments
Labels
discuss Feature:ILM Team:Cloud Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more

Comments

@cjcenizal
Copy link
Contributor

Overview

On a 7.10 I/O optimized deployment on Cloud, the user has the option of selecting node roles or custom node attributes for controlling data allocation in ILM.

Node roles

When the user selects node roles, the UI indicates that warm nodes have been configured for the warm data tier, and that cold nodes have been configured for the cold data tier.

image

image

Custom node attributes

When the user selects custom node attributes, they're prompted to add some to elasticsearch.yml.

image

image

Node configuration

Some nodes in the cluster have been configured with a combination of "roles": ["data"] and "data": true.

Questions

  1. [ILM] Cloud-specific changes for 7.10 #79650 changes the cold phase prompt for the node role option to prompt the user to add a cold tier in Cloud if no node has been tagged with the data_cold node role. Shouldn't we update the warm phase with a similar prompt?

  2. Cloud users can't add custom node attributes to their elasticsearch.yml. What would be the appropriate guidance for a Cloud user?

CC @bleskes @jloleysens @jethr0null

@cjcenizal cjcenizal added discuss Team:Cloud Feature:ILM Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more labels Oct 7, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/es-ui (Team:Elasticsearch UI)

@cjcenizal
Copy link
Contributor Author

cjcenizal commented Oct 14, 2020

ECE vs. Cloud vs. on-prem

At the highest-level, there are different user experiences for users of ECE, Cloud, and on-prem. Long-term we'll want to consider the ECE UX but we currently only have enough information to clearly differentiate between the Cloud and on-prem UX. The remainder of this comment will focus on the Cloud UX.

Cloud

We need to consider two milestone states, which I'll call current milestone and future milestone. Here's how we can compare them in terms of functionality that impacts ILM.

Current milestone Future milestone
node.settings.data true false
Custom node attributes Not supported Not supported
System-defined node attributes* Supported Supported
Node roles Not supported Supported
Warm tier Supported only on hot/warm deployments node.attrs.data:warm Supported on all deployments, disabled by default node.attrs.data:warm roles: data_warm (optional)
Cold tier Not supported on any deployments Supported on all deployments, disabled by default node.attrs.data:cold roles: data_cold
  • Note that system-defined node attributes will be supported through 8.0. This generally implies that it makes sense to give the user the option to set data allocation to use custom node attributes, except in some scenarios described below.

The "cold slider switch"

This has also been referred to as the migration/breaking change triggered by moving users to node roles on cloud.

Within the future milestone, there are two states separated by an event.

The first state is before the user has ever enabled the cold slider. In this state, the warm nodes in the deployment will only have custom node attributes on them (node.attrs.data:warm) and they won't have node roles (roles: data_warm).

The event that occurs is the "cold slider switch", in which the user enables the cold slider for the first time (or performs a similar action the triggers the same event, for example enabling autoscaling).

This event triggers the transition to the second state, in which the warm nodes in the deployment have both custom node attributes (node.attrs.data:warm) and node roles (roles: data_warm) and cold nodes are added to the deployment. They also have both custom node attributes (node.attrs.data_cold) and node roles (roles: data_cold).

Kibana ILM UX

Given the above, we need to consider the impact each of these milestones will have on the Kibana ILM UX. All of the work below is assumed to ship with 7.10 and subsequent releases.

Current milestone

Remove data allocation form for non-hot/warm deployments

DEFERRED

Hot/warm sliders are only supported on the hot/warm deployment, so that should be the only deployment type that lets the user configure Data Allocation at all. This requires a way for Kibana to detect the deployment type. Note that once this option is removed, the user will never be prompted to edit elasticsearch.yml, because hot/warm deployments (and all deployments in the future milestone) will have predefined node attributes.

We're going to consider this out of the current scope.

Remove node role data allocation options

DONE: #79650

Node roles aren't supported in the current milestone, so we should remove this option from the UI when the current milestone is detected.

Future milestone

Warm tier allocation

QUESTION: Do we want to allow allocation using node roles if the user hasn't enabled them yet?

We've been working in #80512 with the assumption that we can direct the user to Cloud to enable node roles for the warm tier. However, the cold slider switch is the only event that triggers this transition. Absent any changes on the Cloud side, directing users to Cloud to enable node roles for the warm tier doesn't make sense.

An alternative is to disallow warm tier allocation using node roles until they've been enabled via the cold slider.

In this scenario, a user attempting to set data allocation for the warm tier will only be shown the "Off" and "Custom" (node attribute) options when they are in the pre-cold slider switch state. After the cold slider switch, they'll gain the "Default" (node role) option. This scenario doesn't require any changes on the Cloud side.

Cold tier allocation

DONE: #79650

The user will be presented the option to select "Default" (node role), "Off", and "Custom" (node attribute) allocation. When the user selects "Default", ILM will prompt them to enable the cold tier in Cloud if there are no cold data tier node roles.

Contracts with Cloud

node.settings.data is true for the current milestone, and false for the future milestone

In order to fulfill the above UX, Kibana needs to be able to determine whether Cloud is on the current milestone or the future milestone. It will use the value of the node.settings.data setting to determine this.

node.settings.data falseness will indicate to Kibana that we are both in "future milestone" AND that data tier sliders are available on Cloud; this will trigger us to show Data tier option for warm and cold phase AND it will trigger us to show the CTA for users to activate cold tier via their deployment. Users will be directed to cloud to interact with the cold tier slider, prompting the "cold tier switch" (or migration to data roles).

@zanbel
Copy link

zanbel commented Oct 18, 2020

QUESTION: Do we want to allow allocation using node roles if the user hasn't enabled them yet?

I'm sure what is the expected behavior for example for self-managed clusters in those scenarios, but I don't think we should.

An alternative is to disallow warm tier allocation using node roles until they've been enabled via the cold slider.

+1 and just a small nitpick, which shouldn't change anything here, but the migration to using the new data tier roles can be triggered by other events, such as enabling autoscaling for example.

@cjcenizal
Copy link
Contributor Author

Closing in favor of #80023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Feature:ILM Team:Cloud Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more
Projects
None yet
Development

No branches or pull requests

3 participants