Provide guidance of "Custom" allocation behavior in ILM #96111

cjcenizal · 2021-04-02T00:48:39Z

Release note

The Index Lifecycle Management UI makes allocation behavior clearer when you select the "Custom" allocation option, but don't select a node attribute or if no node attributes are available.

Summary

Fixes #91254

This PR intends to clarify allocation behavior to the user when the user selects the "Custom" allocation option, but doesn't select a node attribute or if no node attributes are available.

Refactoring

I significantly refactored the way these conditions are communicated by the code.

I found DefaultAllocationNotice and DefaultAllocationWarning hard to reason about, because the names are so similar and I kept forgetting what the difference was. So I renamed DefaultAllocationNotice -> WillUseFallbackTierNotice/WillUseFallbackTierUsingNodeAttributesNotice and DefaultAllocationWarning -> NoTiersAvailableNotice/NoTiersAvailableUsingNodeAttributesNotice to differentiate them and communicate their purpose.
I removed some dead code pertaining to the frozen tier since that tier no longer supports allocation, and updated the pertinent types.
I extracted out and grouped related condition-based variables like noTiersAvailable, willUseFallbackTier, isUsingDeprecatedDataRoleConfig, and hasNodeAttributes, so you can discern which conditions drive the behavior of DataTierAllocationField at a glance. This also enabled a nice mirror structure of the two logic branches for handling the node_roles and node_attrs selections.

Scenarios

There are four general scenarios requiring different types of guidance.

Condition	Behavior	Component
1. Data nodes are in use	Indices will allocate to data nodes	`DefaultToDataNodesNotice` (the option label also provides guidance)
2. Data tiers are available for the given phase's tier	Indices will allocate to data tiers	`DefaultToDataTiersNotice`
3. Data tiers are available but not for the given phase's tier	Indices will allocate to a fallback data tier	`WillUseFallbackTierUsingNodeAttributesNotice`
4. No data tiers are available for the given phases's tier or as a fallback	Allocation won't occur	`NoTiersAvailableUsingNodeAttributesNotice`

Cloud-specific scenario

I also updated the code to hide the "Allocate to available data nodes" option when the user is on Cloud and node roles are in use, because that means they switched their data nodes over to use node roles.

Steps to test each scenario

Sometimes you'll need to edit data_tier_allocation_field.tsx to indirectly simulate the conditions of the scenario, and sometimes you'll need to edit elasticsearch.yml to directly configure the scenario. If you need to edit elasticsearch.yml:

Configure .es/8.0.0/config/elasticsearch.yml with the indicated settings.
Every time you configure this file, you need to restart ES.
Remember to start ES by running .es/8.0.0/bin/elasticsearch so you don't reinstall the snapshot and lose your config changes.

1. Data nodes are in use, so indices will allocate to data nodes

If there are node attributes available to choose from, the user will receive this guidance from the default option.

/* Line 56 of data_tier_allocation_field.tsx */
// const { nodesByRoles, nodesByAttributes, isUsingDeprecatedDataRoleConfig } = data!;
const nodesByRoles = {};
const nodesByAttributes = { 'key:value' : 'node-id' };
const isUsingDeprecatedDataRoleConfig = true;

If there aren't any node attributes, then we'll show the user a callout using the DefaultToDataNodesNotice component.

/* Line 56 of data_tier_allocation_field.tsx */
// const { nodesByRoles, nodesByAttributes, isUsingDeprecatedDataRoleConfig } = data!;
const nodesByRoles = {};
const nodesByAttributes = {};
const isUsingDeprecatedDataRoleConfig = true;

2. Data tiers are available for the given phase's tier, so indices will allocate to data tiers

The callout dynamically changes to tell you which tier will be used, depending on the phase it's in, using the DefaultToDataTiersNotice component.

# elasticsearch.yml
node.roles: [master, remote_cluster_client, data_content, data_warm, data_cold]

Warm

Cold

3. Data tiers are available but not for the given phase's tier, so indices will allocate to a fallback data tier

The callout dynamically changes to tell the user which tier will be used, depending on the phase it's in. It also dynamically changes to tell the user which fallback tier will be used. This uses the WillUseFallbackTierUsingNodeAttributesNotice component.

# elasticsearch.yml
node.roles: [master, remote_cluster_client, data_content, data_hot]

Warm

Cold

4. No data tiers are available for the given phases's tier or as a fallback, so allocation won't occur

This uses the NoTiersAvailableUsingNodeAttributesNotice component.

# elasticsearch.yml
node.roles: [master, remote_cluster_client, data_content]

Cloud-specific scenario

When the user is on Cloud and data nodes are in use, the user can select "Allocate to available data nodes".

/* Line 56 of data_tier_allocation_field.tsx */
// const { nodesByRoles, nodesByAttributes, isUsingDeprecatedDataRoleConfig } = data!;
const nodesByRoles = {};
const nodesByAttributes = { 'key:value' : 'node-id' };
const isUsingDeprecatedDataRoleConfig = true;

const hasNodeAttributes = Boolean(Object.keys(nodesByAttributes ?? {}).length);
const isCloudEnabled = true;//cloud?.isCloudEnabled ?? false;

When the user is on Cloud and node roles are available (inferring data nodes are no longer in use), the user can't select "Allocate to available data nodes".

# elasticsearch.yml
node.attr.custom: my-attribute
node.roles: [master, remote_cluster_client, data_content, data_hot]

/* Line 56 of data_tier_allocation_field.tsx */
const { nodesByRoles, nodesByAttributes, isUsingDeprecatedDataRoleConfig } = data!;

const hasNodeAttributes = Boolean(Object.keys(nodesByAttributes ?? {}).length);
const isCloudEnabled = true;//cloud?.isCloudEnabled ?? false;

Checklist

Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
Unit or functional tests were updated or added to match the most common scenarios

* Provide allocation behavior guidance when the user has selected Custom, but no attributes are available and: ...data nodes are in use, so indices will allocate to data nodes. ...data tiers are available, so indices will allocate to data tiers. ...data tiers are available but not for the given phase's tier, so indices will be allocated to a fallback data tier. ...no data tiers are available, so allocation won't occur (TODO: Check if this is even possible). * Change the label for the Custom > 'Do not modify allocation configuration' option to 'Allocate to available data nodes' to clarify behavior. * Hide the Custom > 'Allocate to available data nodes' option when on Cloud and data nodes are in use.

…to make it easier to reason about.

…tion but no data tiers are available.

cjcenizal · 2021-04-21T03:48:43Z

...mponents/phases/shared_fields/data_tier_allocation_field/components/data_tier_allocation.tsx

+   * using node roles in our Node config yet. See {@link ListNodesRouteResponse} for information about how this is
+   * detected.
+   */
+  const disableDataTierOption = Boolean(isCloudEnabled && isUsingDeprecatedDataRoleConfig);


This was originally being defined in data_tier_allocation_field.tsx and passed in as a prop. I refactored the code to define this value locally, derived from the underlying conditions, to make it easier to reason about when reading this file. There's no change to the original behavior.

cjcenizal · 2021-04-21T03:52:38Z

...cy/components/phases/shared_fields/data_tier_allocation_field/components/node_allocation.tsx

+  //
+  // On prem, users should have the freedom to choose this option, even if they're using node roles.
+  // So we always give them this option.
+  if (!isCloudEnabled || isUsingDeprecatedDataRoleConfig) {


This is a behavioral change. It's the condition that will hide the "Allocate to available data nodes" custom allocation option on Cloud when node roles are available.

debadair

Left some suggestions--let me know if you have any questions.

debadair · 2021-04-22T00:12:46Z

.../phases/shared_fields/data_tier_allocation_field/components/default_to_data_tiers_notice.tsx

+  title: {
+    warm: i18n.translate(
+      'xpack.indexLifecycleMgmt.warmPhase.dataTier.defaultAllocationNotAvailableTitle',
+      { defaultMessage: 'Indices will be allocated to the warm tier' }


Suggested change

{ defaultMessage: 'Indices will be allocated to the warm tier' }

{ defaultMessage: 'Move data to warm nodes.' }

The updated callout content will be:

Move data to warm nodes
Define custom node attributes in elasticsearch.yml to allocate indices based on these attributes instead.

In this particular situation, the user has selected the "Custom" allocation option and probably intends to use custom node attributes to control allocation behavior. However, because they haven't defined any custom node attributes, allocation will behave unexpectedly. Its precise behavior varies depending on how the cluster is configured and which phase of the policy the user is configuring.

"Move data to warm nodes" sounds imperative to me, as if the user intentionally chooses this option in order to allocate to warm nodes. But the scenario is more like "You probably didn't intend this, so we just wanted to be clear about what's going to happen." So I wonder if this tone is appropriate for the uncertainty of the scenario -- I think we really want users to doubt their choice here.

Is this making any sense @debadair? Does it change the way you're seeing this copy?

debadair · 2021-04-22T00:13:06Z

.../phases/shared_fields/data_tier_allocation_field/components/default_to_data_tiers_notice.tsx

+    ),
+    cold: i18n.translate(
+      'xpack.indexLifecycleMgmt.coldPhase.dataTier.defaultAllocationNotAvailableTitle',
+      { defaultMessage: 'Indices will be allocated to the cold tier' }


Suggested change

{ defaultMessage: 'Indices will be allocated to the cold tier' }

{ defaultMessage: 'Move data to cold nodes.' }

I have the same concerns here as above.

.../phases/shared_fields/data_tier_allocation_field/components/default_to_data_tiers_notice.tsx

+  },
+  body: i18n.translate('xpack.indexLifecycleMgmt.editPolicy.defaultToDataTiersDescription', {
+    defaultMessage:
+      'Define custom node attributes in elasticsearch.yml to allocate indices based on these attributes instead.',


.../phases/shared_fields/data_tier_allocation_field/components/default_to_data_nodes_notice.tsx

+
+const i18nTexts = {
+  title: i18n.translate('xpack.indexLifecycleMgmt.editPolicy.defaultToDataNodesLabel', {
+    defaultMessage: 'Indices will be allocated to available data nodes',


.../phases/shared_fields/data_tier_allocation_field/components/default_to_data_nodes_notice.tsx

+  }),
+  body: i18n.translate('xpack.indexLifecycleMgmt.editPolicy.defaultToDataNodesDescription', {
+    defaultMessage:
+      'Define custom node attributes in elasticsearch.yml to allocate indices based on these attributes instead.',


...nts/phases/shared_fields/data_tier_allocation_field/components/no_tiers_available_notice.tsx

+    }),
+    body: i18n.translate('xpack.indexLifecycleMgmt.frozenPhase.dataTier.noTiersAvailableBody', {
+      defaultMessage:
+        'Assign at least one node to the frozen, cold, warm, or hot tier to use role-based allocation. The policy will fail to complete allocation if there are no available nodes.',


...cy/components/phases/shared_fields/data_tier_allocation_field/components/node_allocation.tsx

-    { defaultMessage: 'Do not modify allocation configuration' }
+  allocateToDataNodesOption: i18n.translate(
+    'xpack.indexLifecycleMgmt.editPolicy.nodeAllocation.allocateToDataNodesOption',
+    { defaultMessage: 'Allocate to available data nodes' }


debadair · 2021-04-22T02:03:21Z

...phases/shared_fields/data_tier_allocation_field/components/will_use_fallback_tier_notice.tsx

+    body: (nodeRole: DataTierRole) =>
+      i18n.translate('xpack.indexLifecycleMgmt.warmPhase.dataTier.willUseFallbackTierDescription', {
+        defaultMessage:
+          'This policy will move data in the warm phase to {tier} tier nodes instead.',


I think move is a little misleading, as the net effect is likely to be that it isn't moved to a different tier, it stays where it is.

Suggested change

'This policy will move data in the warm phase to {tier} tier nodes instead.',

If no warm nodes are available, data is store in the {tier} tier.',

Great point!

With this change the callout will state:

No nodes assigned to the warm tier
If no warm nodes are available, data is stored in the hot tier.

I wonder if this sounds a little unclear. The title is definitive about no warm nodes being available, and then the body seems to walk it back by cautioning "if" they're unavailable. But there's no "if" involved -- we know they're unavailable, so maybe we should more directly explain the consequence?

Very bluntly put:

No nodes assigned to the warm tier
Because of this, data is stored in the hot tier.

...phases/shared_fields/data_tier_allocation_field/components/will_use_fallback_tier_notice.tsx

+    body: (nodeRole: DataTierRole) =>
+      i18n.translate('xpack.indexLifecycleMgmt.coldPhase.dataTier.willUseFallbackTierDescription', {
+        defaultMessage:
+          'This policy will move data in the cold phase to {tier} tier nodes instead.',


debadair · 2021-04-22T02:19:07Z

...phases/shared_fields/data_tier_allocation_field/components/will_use_fallback_tier_notice.tsx

+  'xpack.indexLifecycleMgmt.editPolicy.customizeWithNodeAttributeDescription',
+  {
+    defaultMessage:
+      'Define custom node attributes in elasticsearch.yml to allocate indices based on these attributes.',


It's not clear why this is relevant in the context of the fallback tiers?

This ties back to #96111 (comment). In the situation where this message is shown to the user, they've selected "Custom" allocation but there are no custom node attributes available. If they've chosen "Custom" I expect their intention would be to use custom node attributes to control allocation, otherwise they should use the "Recommended (data tiers)" option. I've updated this to subtly direct them to use built-in node roles per your earlier comment.

…ge people to use the built-in node roles.

…est helpers to define suite-specific helper interfaces, to improve maintainability.

elasticmachine · 2021-04-25T01:45:24Z

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

cjcenizal · 2021-04-25T01:49:14Z

@yuliacech @jloleysens As you review this, could you please also take a look at how I restructured the CITs? I split up the node allocation tests into separate files to make each file easier to read and to also make the categories of functionality under test easier to discover. I also created a helper file per test file so we can narrowly scope each helper's interface to the tests' needs, which I think will improve maintainability because it's easier to track which actions are used where.

I'm mostly concerned with whether or not this direction is compatible with the direction you want to take with refactoring these tests. Is it close enough to what you have in mind for me to move forward with this? If so then I'll add additional tests to cover the changes in this PR. I'll also do an additional cleanup pass on the test files I touched to remove any redundant or unnecessary configuration (e.g. beforeEach calls which overlap and override one another).

cjcenizal · 2021-04-25T16:22:21Z

@elasticmachine merge upstream

yuliacech

Hi @cjcenizal, this work looks great, thanks a lot for doing this! I'm happy with it being merged, just a couple of non blocking comments

When there is no data tiers to fallback to or when there is no data tier for a concrete phase, would that be useful to link to this guide? To help the user configure their node roles correctly. This might not be applicable on Cloud though I guess.
About the test helpers: Thanks a lot for clarifying your reasoning about using 'helpers' file for individual test files. I think that works but I still would like to separate helpers that create edit policy actions like 'savePolicy' etc into a logical group. As you suggested, maybe we could move them in a separate folder inside edit_policy folder (I don't think they are used by other tests then edit policy)

cjcenizal · 2021-04-30T17:49:32Z

Thanks @yuliacech! I created #98960 to track your first point about the docs. I am open to any changes you'd like to make to the test structure. I'd like to limit this PRs scope to node allocation so let's handle that in subsequent PRs.

debadair

Just a couple minor suggestions. Also, there might be an instance where "Allocate to available data nodes" is still showing up in the drop down instead of "Any data node" when there are custom attributes configured? (It's showing up in the screen cap, but I'm not seeing it in the diff.)

...ds/data_tier_allocation_field/components/no_tiers_available_using_node_attributes_notice.tsx

+        {i18n.translate(
+          'xpack.indexLifecycleMgmt.dataTier.noTiersAvailableUsingNodeAttributesDescription',
+          {
+            defaultMessage: 'There are no available nodes for data allocation.',


...ata_tier_allocation_field/components/will_use_fallback_tier_using_node_attributes_notice.tsx

+        {i18n.translate(
+          'xpack.indexLifecycleMgmt.dataTier.willUseFallbackTierUsingNodeAttributesDescription',
+          {
+            defaultMessage: 'Data will be allocated to the {tier} tier.',


cjcenizal · 2021-05-01T02:23:17Z

@debadair, thanks! Copy updated, conditions checked, screenshots uploaded.

kibanamachine · 2021-05-01T04:14:15Z

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
`indexLifecycleManagement`	206	211	+5

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
`indexLifecycleManagement`	247.1KB	248.8KB	+1.8KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
`indexLifecycleManagement`	50.1KB	50.3KB	+189.0B

History

💚 Build #123450 succeeded fd44a88
💔 Build #123449 failed 63c0d1b981a53c027e1e1c1ae3c2b97634cea05e
💔 Build #123102 failed d3f480f
💛 Build #122712 was flaky 3bae91c
💚 Build #122668 succeeded 4e06e3b

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

* Provide allocation behavior guidance when the user has selected Custom, but no attributes are available and: ...data nodes are in use, so indices will allocate to data nodes. ...data tiers are available, so indices will allocate to data tiers. ...data tiers are available but not for the given phase's tier, so indices will be allocated to a fallback data tier. ...no data tiers are available, so allocation won't occur. * Provide link to the migration docs. * Adjust copy to consistently notify the user that node attributes are missing and guide them to use role-based allocation. * Localize disableDataTierOption flag instead of passing it as a prop, to make it easier to reason about. * Clarify the scenario in which the user has selected node_attrs allocation but no data tiers are available. * Remove inapplicable frozen tier from NoTiersAvailableNotice. * Refactor and update tests. * Split up node allocation tests to improve discoverability. Refactor test helpers to define suite-specific helper interfaces, to improve maintainability. * Refactor tests to make the [using node attributes, using node roles] branch and the various conditions within easier to contrast and compare. * Add coverage for NoTiersAvailableUsingNodeAttributesNotice scenario. * Add some helpers for improved maintainability and readability. * Create helpers/types file to store extracted Phase type.

) * Provide allocation behavior guidance when the user has selected Custom, but no attributes are available and: ...data nodes are in use, so indices will allocate to data nodes. ...data tiers are available, so indices will allocate to data tiers. ...data tiers are available but not for the given phase's tier, so indices will be allocated to a fallback data tier. ...no data tiers are available, so allocation won't occur. * Provide link to the migration docs. * Adjust copy to consistently notify the user that node attributes are missing and guide them to use role-based allocation. * Localize disableDataTierOption flag instead of passing it as a prop, to make it easier to reason about. * Clarify the scenario in which the user has selected node_attrs allocation but no data tiers are available. * Remove inapplicable frozen tier from NoTiersAvailableNotice. * Refactor and update tests. * Split up node allocation tests to improve discoverability. Refactor test helpers to define suite-specific helper interfaces, to improve maintainability. * Refactor tests to make the [using node attributes, using node roles] branch and the various conditions within easier to contrast and compare. * Add coverage for NoTiersAvailableUsingNodeAttributesNotice scenario. * Add some helpers for improved maintainability and readability. * Create helpers/types file to store extracted Phase type.

…)" This reverts commit 8ae49a4.

…) (#99004)" This reverts commit da4daa7.

spalger · 2021-05-01T08:18:42Z

Hey CJ, I had to revert this PR and the 7.x backport because for some reason as soon as it was merged master started to fail with:

22:26:23   info [  kibana  ] Checking Windows for paths > 200 characters
22:26:26     │ERROR failure 3 sec
22:26:26     │ERROR Error: Windows has a path limit of 260 characters so we limit the length of paths in Kibana to 200 characters  and the following files exceed this limit:
22:26:26     │       - x-pack/plugins/index_lifecycle_management/target/types/public/application/sections/edit_policy/components/phases/shared_fields/data_tier_allocation_field/components/default_to_data_nodes_notice.d.ts.map
22:26:26     │       - x-pack/plugins/index_lifecycle_management/target/types/public/application/sections/edit_policy/components/phases/shared_fields/data_tier_allocation_field/components/default_to_data_tiers_notice.d.ts.map
22:26:26     │       - x-pack/plugins/index_lifecycle_management/target/types/public/application/sections/edit_policy/components/phases/shared_fields/data_tier_allocation_field/components/no_custom_attributes_messages.d.ts.map
22:26:26     │       - x-pack/plugins/index_lifecycle_management/target/types/public/application/sections/edit_policy/components/phases/shared_fields/data_tier_allocation_field/components/no_tiers_available_using_node_attributes_notice.d.ts.map
22:26:26     │       - x-pack/plugins/index_lifecycle_management/target/types/public/application/sections/edit_policy/components/phases/shared_fields/data_tier_allocation_field/components/node_role_to_fallback_tier_map.d.ts.map
22:26:26     │       - x-pack/plugins/index_lifecycle_management/target/types/public/application/sections/edit_policy/components/phases/shared_fields/data_tier_allocation_field/components/will_use_fallback_tier_notice.d.ts.map
22:26:26     │       - x-pack/plugins/index_lifecycle_management/target/types/public/application/sections/edit_policy/components/phases/shared_fields/data_tier_allocation_field/components/will_use_fallback_tier_using_node_attributes_notice.d.ts.map

Seems like this should be failing in the PR too, filed #99005 to remind me to look into it on Monday. Would you mind resubmitting this PR and considering some shorter file names before merging? Hopefully we can track down what the problem is quickly, but your new PR might not be validating the new path lengths so please use caution. Thanks!

…LM (elastic#96111)"" This reverts commit d40adb9.

cjcenizal force-pushed the bug/duplicate-allocation-ux branch from b621b41 to 7e66be9 Compare April 2, 2021 16:50

cjcenizal added 3 commits April 5, 2021 11:28

Localize disableDataTierOption flag instead of passing it as a prop, …

fe5850b

…to make it easier to reason about.

Clarify the scenario in which the user has selected node_attrs alloca…

0ebf824

…tion but no data tiers are available.

cjcenizal force-pushed the bug/duplicate-allocation-ux branch from 7e66be9 to 0ebf824 Compare April 5, 2021 19:28

cjcenizal commented Apr 21, 2021

View reviewed changes

cjcenizal changed the title ~~Provide guidance of allocation behavior in ILM~~ Provide guidance of "Custom" allocation behavior in ILM Apr 21, 2021

jrodewig requested a review from debadair April 21, 2021 14:32

debadair reviewed Apr 22, 2021

View reviewed changes

cjcenizal added 4 commits April 24, 2021 16:41

Merge branch 'master' into bug/duplicate-allocation-ux

f257625

Remove inapplicable frozen tier from NoTiersAvailableNotice.

67474bc

Adjust copy for clarity: data remains on fallback nodes and subtly ur…

1f4ffb2

…ge people to use the built-in node roles.

Split up node allocation tests to improve discoverability. Refactor t…

8361de4

…est helpers to define suite-specific helper interfaces, to improve maintainability.

cjcenizal added enhancement New value added to drive a business result Feature:ILM Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more v7.14.0 v8.0.0 labels Apr 25, 2021

cjcenizal marked this pull request as ready for review April 25, 2021 01:45

cjcenizal requested a review from a team as a code owner April 25, 2021 01:45

cjcenizal requested review from yuliacech and jloleysens April 25, 2021 01:45

cjcenizal added release_note:enhancement and removed enhancement New value added to drive a business result labels Apr 25, 2021

kibanamachine and others added 2 commits April 25, 2021 12:22

Merge branch 'master' into bug/duplicate-allocation-ux

b9a9cff

Merge branch 'master' into bug/duplicate-allocation-ux

8f17c47

yuliacech approved these changes Apr 30, 2021

View reviewed changes

cjcenizal mentioned this pull request Apr 30, 2021

Link ILM users to data tier configuration docs #98960

Open

debadair approved these changes Apr 30, 2021

View reviewed changes

cjcenizal added 2 commits April 30, 2021 15:03

Merge branch 'master' into bug/duplicate-allocation-ux

0e7b903

Final copy polish.

ffa283e

cjcenizal merged commit 8ae49a4 into elastic:master May 1, 2021

cjcenizal deleted the bug/duplicate-allocation-ux branch May 1, 2021 04:37

cjcenizal mentioned this pull request May 1, 2021

[7.x] Provide guidance of "Custom" allocation behavior in ILM (#96111) #99004

Merged

spalger added a commit that referenced this pull request May 1, 2021

Revert "Provide guidance of "Custom" allocation behavior in ILM (#96111…

d40adb9

…)" This reverts commit 8ae49a4.

spalger added a commit that referenced this pull request May 1, 2021

Revert "Provide guidance of "Custom" allocation behavior in ILM (#96111…

570326e

…) (#99004)" This reverts commit da4daa7.

spalger mentioned this pull request May 1, 2021

[ci/build] seems that the path length-limit is not enforced in PRs? #99005

Closed

spalger added the reverted label May 1, 2021

cjcenizal mentioned this pull request May 1, 2021

Reintroduce 96111: Provide guidance of "Custom" allocation behavior in ILM #99007

Merged

cjcenizal added a commit to cjcenizal/kibana that referenced this pull request May 3, 2021

Revert "Revert "Provide guidance of "Custom" allocation behavior in I…

ad6844a

…LM (elastic#96111)"" This reverts commit d40adb9.

spalger mentioned this pull request May 3, 2021

[x-pack/build] exclude plugins/*/target when copying source to build #99009

Merged

cjcenizal mentioned this pull request May 6, 2021

Provide data allocation doc links in ILM #97385

Closed

cjcenizal mentioned this pull request May 24, 2021

[ILM] Refactor edit policy helpers #98031

Closed

yuliacech mentioned this pull request Jun 1, 2021

[ILM] Split edit policy test helpers into separate files #100807

Merged

yuliacech mentioned this pull request Jun 17, 2021

[ILM] Split edit policy helpers file into separate domain oriented files #102383

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Provide guidance of "Custom" allocation behavior in ILM #96111

Provide guidance of "Custom" allocation behavior in ILM #96111

cjcenizal commented Apr 2, 2021 •

edited

Loading

cjcenizal Apr 21, 2021

cjcenizal Apr 21, 2021 •

edited

Loading

debadair left a comment

debadair Apr 22, 2021

cjcenizal Apr 24, 2021 •

edited

Loading

debadair Apr 22, 2021

cjcenizal Apr 24, 2021

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

debadair Apr 22, 2021

cjcenizal Apr 24, 2021

cjcenizal Apr 24, 2021 •

edited

Loading

This comment was marked as resolved.

debadair Apr 22, 2021

cjcenizal Apr 24, 2021 •

edited

Loading

elasticmachine commented Apr 25, 2021

cjcenizal commented Apr 25, 2021 •

edited

Loading

cjcenizal commented Apr 25, 2021

yuliacech left a comment

cjcenizal commented Apr 30, 2021 •

edited

Loading

debadair left a comment

This comment was marked as resolved.

This comment was marked as resolved.

cjcenizal commented May 1, 2021 •

edited

Loading

kibanamachine commented May 1, 2021

spalger commented May 1, 2021

	{ defaultMessage: 'Indices will be allocated to the warm tier' }
	{ defaultMessage: 'Move data to warm nodes.' }

	{ defaultMessage: 'Indices will be allocated to the cold tier' }
	{ defaultMessage: 'Move data to cold nodes.' }

	'This policy will move data in the warm phase to {tier} tier nodes instead.',
	If no warm nodes are available, data is store in the {tier} tier.',

Provide guidance of "Custom" allocation behavior in ILM #96111

Provide guidance of "Custom" allocation behavior in ILM #96111

Conversation

cjcenizal commented Apr 2, 2021 • edited Loading

Release note

Summary

Refactoring

Scenarios

Cloud-specific scenario

Steps to test each scenario

1. Data nodes are in use, so indices will allocate to data nodes

2. Data tiers are available for the given phase's tier, so indices will allocate to data tiers

Warm

Cold

3. Data tiers are available but not for the given phase's tier, so indices will allocate to a fallback data tier

Warm

Cold

4. No data tiers are available for the given phases's tier or as a fallback, so allocation won't occur

Cloud-specific scenario

Checklist

cjcenizal Apr 21, 2021

Choose a reason for hiding this comment

cjcenizal Apr 21, 2021 • edited Loading

Choose a reason for hiding this comment

debadair left a comment

Choose a reason for hiding this comment

debadair Apr 22, 2021

Choose a reason for hiding this comment

cjcenizal Apr 24, 2021 • edited Loading

Choose a reason for hiding this comment

debadair Apr 22, 2021

Choose a reason for hiding this comment

cjcenizal Apr 24, 2021

Choose a reason for hiding this comment

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

debadair Apr 22, 2021

Choose a reason for hiding this comment

cjcenizal Apr 24, 2021

Choose a reason for hiding this comment

cjcenizal Apr 24, 2021 • edited Loading

Choose a reason for hiding this comment

This comment was marked as resolved.

debadair Apr 22, 2021

Choose a reason for hiding this comment

cjcenizal Apr 24, 2021 • edited Loading

Choose a reason for hiding this comment

elasticmachine commented Apr 25, 2021

cjcenizal commented Apr 25, 2021 • edited Loading

cjcenizal commented Apr 25, 2021

yuliacech left a comment

Choose a reason for hiding this comment

cjcenizal commented Apr 30, 2021 • edited Loading

debadair left a comment

Choose a reason for hiding this comment

This comment was marked as resolved.

This comment was marked as resolved.

cjcenizal commented May 1, 2021 • edited Loading

kibanamachine commented May 1, 2021

💚 Build Succeeded

Metrics [docs]

Module Count

Async chunks

Page load bundle

History

spalger commented May 1, 2021

cjcenizal commented Apr 2, 2021 •

edited

Loading

cjcenizal Apr 21, 2021 •

edited

Loading

cjcenizal Apr 24, 2021 •

edited

Loading

cjcenizal Apr 24, 2021 •

edited

Loading

cjcenizal Apr 24, 2021 •

edited

Loading

cjcenizal commented Apr 25, 2021 •

edited

Loading

cjcenizal commented Apr 30, 2021 •

edited

Loading

cjcenizal commented May 1, 2021 •

edited

Loading