Remove "beta" modifier from ILM documentation (#37326)
This commit is contained in:
Lee Hinman
GitHub
parent
e6d3d85db4
commit
04dcb13ac4
|
|
@ -6,8 +6,6 @@
|
|||
<titleabbrev>Delete policy</titleabbrev>
|
||||
++++
|
||||
|
||||
beta[]
|
||||
|
||||
Deletes a lifecycle policy.
|
||||
|
||||
==== Request
|
||||
|
|
|
|||
|
|
@ -6,8 +6,6 @@
|
|||
<titleabbrev>Explain lifecycle</titleabbrev>
|
||||
++++
|
||||
|
||||
beta[]
|
||||
|
||||
Shows an index's current lifecycle status.
|
||||
|
||||
==== Request
|
||||
|
|
|
|||
|
|
@ -6,8 +6,6 @@
|
|||
<titleabbrev>Get policy</titleabbrev>
|
||||
++++
|
||||
|
||||
beta[]
|
||||
|
||||
Retrieves a lifecycle policy.
|
||||
|
||||
==== Request
|
||||
|
|
|
|||
|
|
@ -6,8 +6,6 @@
|
|||
<titleabbrev>Get {ilm} status</titleabbrev>
|
||||
++++
|
||||
|
||||
beta[]
|
||||
|
||||
Retrieves the current {ilm} ({ilm-init}) status.
|
||||
|
||||
==== Request
|
||||
|
|
|
|||
|
|
@ -1,8 +1,6 @@
|
|||
[[index-lifecycle-management-api]]
|
||||
== {ilm-cap} API
|
||||
|
||||
beta[]
|
||||
|
||||
You can use the following APIs to manage policies on indices. See
|
||||
<<index-lifecycle-management,Managing the index lifecycle>> for more information
|
||||
about Index Lifecycle Management.
|
||||
|
|
|
|||
|
|
@ -6,8 +6,6 @@
|
|||
<titleabbrev>Move to step</titleabbrev>
|
||||
++++
|
||||
|
||||
beta[]
|
||||
|
||||
Triggers execution of a specific step in the lifecycle policy.
|
||||
|
||||
==== Request
|
||||
|
|
|
|||
|
|
@ -6,8 +6,6 @@
|
|||
<titleabbrev>Create policy</titleabbrev>
|
||||
++++
|
||||
|
||||
beta[]
|
||||
|
||||
Creates or updates lifecycle policy. See <<ilm-policy-definition,Policy phases and actions>>
|
||||
for definitions of policy components.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,8 +6,6 @@
|
|||
<titleabbrev>Remove policy</titleabbrev>
|
||||
++++
|
||||
|
||||
beta[]
|
||||
|
||||
Removes the assigned lifecycle policy from an index.
|
||||
|
||||
==== Request
|
||||
|
|
|
|||
|
|
@ -6,8 +6,6 @@
|
|||
<titleabbrev>Retry policy</titleabbrev>
|
||||
++++
|
||||
|
||||
beta[]
|
||||
|
||||
Retry executing the policy for an index that is in the ERROR step.
|
||||
|
||||
==== Request
|
||||
|
|
|
|||
|
|
@ -6,8 +6,6 @@
|
|||
<titleabbrev>Start {ilm}</titleabbrev>
|
||||
++++
|
||||
|
||||
beta[]
|
||||
|
||||
Start the {ilm} ({ilm-init}) plugin.
|
||||
|
||||
==== Request
|
||||
|
|
|
|||
|
|
@ -6,8 +6,6 @@
|
|||
<titleabbrev>Stop {ilm}</titleabbrev>
|
||||
++++
|
||||
|
||||
beta[]
|
||||
|
||||
Stop the {ilm} ({ilm-init}) plugin.
|
||||
|
||||
==== Request
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@
|
|||
[[index-lifecycle-error-handling]]
|
||||
== Index lifecycle error handling
|
||||
|
||||
beta[]
|
||||
|
||||
During Index Lifecycle Management's execution of the policy for an index, it's
|
||||
possible for a step to encounter an error during its execution. When this
|
||||
happens, ILM will move the management state into an "error" step. This halts
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@
|
|||
[[getting-started-index-lifecycle-management]]
|
||||
== Getting started with {ilm}
|
||||
|
||||
beta[]
|
||||
|
||||
Let's jump into {ilm} ({ilm-init}) by working through a hands-on scenario.
|
||||
This section will leverage many new concepts unique to {ilm-init} that
|
||||
you may not be familiar with. The following sections will explore
|
||||
|
|
@ -19,8 +17,6 @@ after 90 days.
|
|||
|
||||
=== Setting up a new policy
|
||||
|
||||
beta[]
|
||||
|
||||
There are many new features introduced by {ilm-init}, but we will only focus on
|
||||
a few that are needed for our example. For starters, we will use the
|
||||
<<ilm-put-lifecycle,Put Policy>> API to define our first policy. Lifecycle
|
||||
|
|
@ -70,8 +66,6 @@ The index will be deleted 90 days after it is rolled over.
|
|||
|
||||
=== Applying a policy to our index
|
||||
|
||||
beta[]
|
||||
|
||||
There are <<set-up-lifecycle-policy,a few ways>> to associate a
|
||||
policy to an index. Since we wish specific settings to be applied to
|
||||
the new index created from Rollover, we will set the policy via
|
||||
|
|
@ -143,8 +137,6 @@ alias to be read-only for the source index.
|
|||
|
||||
=== Checking progress
|
||||
|
||||
beta[]
|
||||
|
||||
Now that we have an index managed by our policy, how do we tell what is going
|
||||
on? Which phase are we in? Is something broken? This section will go over a
|
||||
few APIs and their responses to help us inspect our indices with respect
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@
|
|||
[[index-lifecycle-and-snapshots]]
|
||||
== Restoring snapshots of managed indices
|
||||
|
||||
beta[]
|
||||
|
||||
When restoring a snapshot that contains indices managed by Index Lifecycle
|
||||
Management, the lifecycle will automatically continue to execute after the
|
||||
snapshot is restored. Notably, the `min_age` is relative to the original
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@
|
|||
|
||||
[partintro]
|
||||
--
|
||||
beta[]
|
||||
|
||||
The <<index-lifecycle-management-api,{ilm} ({ilm-init}) APIs>> enable you to
|
||||
automate how you want to manage your indices over time. Rather than simply
|
||||
|
|
|
|||
|
|
@ -1,11 +1,8 @@
|
|||
beta[]
|
||||
[role="xpack"]
|
||||
[testenv="basic"]
|
||||
[[ilm-policy-definition]]
|
||||
== Policy phases and actions
|
||||
|
||||
beta[]
|
||||
|
||||
There are four stages in the index lifecycle, in the order
|
||||
they are executed.
|
||||
|
||||
|
|
@ -26,8 +23,6 @@ phase and the delete phase, while another may define all four phases.
|
|||
|
||||
=== Timing
|
||||
|
||||
beta[]
|
||||
|
||||
Indices enter phases based on a phase's `min_age` parameter.
|
||||
The index will not enter the phase until the index's age is older than that
|
||||
of the `min_age`. The parameter is configured using a time
|
||||
|
|
@ -76,8 +71,6 @@ and transition into the next phase.
|
|||
|
||||
=== Phase Execution
|
||||
|
||||
beta[]
|
||||
|
||||
The current phase definition, of an index's policy being executed, is stored
|
||||
in the index's metadata. The phase and its actions are compiled into a series
|
||||
of discrete steps that are executed sequentially. Since some {ilm-init} actions
|
||||
|
|
@ -89,8 +82,6 @@ executing.
|
|||
|
||||
=== Actions
|
||||
|
||||
beta[]
|
||||
|
||||
The below list shows the actions which are available in each phase.
|
||||
|
||||
* Hot
|
||||
|
|
@ -582,8 +573,6 @@ PUT _ilm/policy/my_policy
|
|||
|
||||
=== Full Policy
|
||||
|
||||
beta[]
|
||||
|
||||
With all of these actions, we can support complex management strategies for our
|
||||
indices. This policy will define an index that will start in the hot phase,
|
||||
rolling over every 50 GB or 7 days. After 30 days it enters the warm phase
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@
|
|||
[[set-up-lifecycle-policy]]
|
||||
== Set up {ilm} policy
|
||||
|
||||
beta[]
|
||||
|
||||
In order for an index to use an {ilm} policy to manage its lifecycle we must
|
||||
first define a lifecycle policy for it to use. The following request creates a
|
||||
policy called `my_policy` in Elasticsearch which we can later use to manage our
|
||||
|
|
@ -49,8 +47,6 @@ To set the policy for an index there are two options:
|
|||
[[applying-policy-to-template]]
|
||||
=== Applying a policy to an index template
|
||||
|
||||
beta[]
|
||||
|
||||
The `index.lifecycle.name` setting can be set in an index template so that it
|
||||
is automatically applied to indexes matching the templates index pattern:
|
||||
|
||||
|
|
@ -95,8 +91,6 @@ create a new index and roll the alias over to use the new index automatically.
|
|||
|
||||
=== Apply a policy to a create index request
|
||||
|
||||
beta[]
|
||||
|
||||
The `index.lifecycle.name` setting can be set on an individual create index
|
||||
request so {ilm} immediately starts managing the index:
|
||||
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@
|
|||
[[start-stop-ilm]]
|
||||
== Start and stop {ilm}
|
||||
|
||||
beta[]
|
||||
|
||||
All indices that are managed by ILM will continue to execute
|
||||
their policies. There may be times when this is not desired on certain
|
||||
indices, or maybe even all the indices in a cluster. For example,
|
||||
|
|
|
|||
|
|
@ -6,8 +6,6 @@
|
|||
<titleabbrev>Update policy</titleabbrev>
|
||||
++++
|
||||
|
||||
beta[]
|
||||
|
||||
You can update an existing lifecycle policy to fix mistakes or change
|
||||
strategies for newly created indices. It is possible to update policy definitions
|
||||
and an index's `index.lifecycle.name` settings independently. To prevent the situation
|
||||
|
|
@ -22,8 +20,6 @@ their effects on policy execution on indices.
|
|||
|
||||
=== Updates to policies not managing indices
|
||||
|
||||
beta[]
|
||||
|
||||
Indices not referencing an existing policy that is updated will not be affected.
|
||||
If an index is assigned to the policy, it will be assigned the latest version of that policy
|
||||
|
||||
|
|
@ -137,8 +133,6 @@ the policy.
|
|||
|
||||
=== Updates to executing policies
|
||||
|
||||
beta[]
|
||||
|
||||
Indices preserve the phase definition from the latest policy version that existed
|
||||
at the time that it entered that phase. Changes to the currently-executing phase within policy updates will
|
||||
not be reflected during execution. This means that updates to the `hot` phase, for example, will not affect
|
||||
|
|
@ -445,8 +439,6 @@ GET my_index/_ilm/explain
|
|||
|
||||
=== Switching policies for an index
|
||||
|
||||
beta[]
|
||||
|
||||
Setting `index.lifecycle.name` to a different policy behaves much like a policy update, but instead of just
|
||||
switching to a different version, it switches to a different policy.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@
|
|||
[[using-policies-rollover]]
|
||||
== Using policies to manage index rollover
|
||||
|
||||
beta[]
|
||||
|
||||
The rollover action enables you to automatically roll over to a new index based
|
||||
on the index size, document count, or age. When a rollover is triggered, a new
|
||||
index is created, the write alias is updated to point to the new index, and all
|
||||
|
|
@ -127,8 +125,6 @@ the new index, enabling indexing to continue uninterrupted.
|
|||
|
||||
=== Skipping Rollover
|
||||
|
||||
beta[]
|
||||
|
||||
The `index.lifecycle.indexing_complete` setting indicates to {ilm} whether this
|
||||
index has already been rolled over. If it is set to `true`, that indicates that
|
||||
this index has already been rolled over and does not need to be rolled over
|
||||
|
|
|
|||
Loading…
Reference in New Issue