[DOCS] Remove redundant ILM attributes (#36808)

docs/reference/ilm/apis/explain.asciidoc

@@ -170,7 +170,7 @@ entered this phase
 <3> The date the loaded policy was last modified
 <4> The epoch time when the loaded policy was last modified
 
-If {ILM} is waiting for a step to complete, the response includes status
+If {ilm-init} is waiting for a step to complete, the response includes status
 information for the step that's being performed on the index.
 
 [source,js]

docs/reference/ilm/apis/get-status.asciidoc

@@ -1,14 +1,14 @@
 [role="xpack"]
 [testenv="basic"]
 [[ilm-get-status]]
-=== Get {ILM} status API
+=== Get {ilm} status API
 ++++
-<titleabbrev>Get {ILM} status</titleabbrev>
+<titleabbrev>Get {ilm} status</titleabbrev>
 ++++
 
 beta[]
 
-Retrieves the current {ilm} status.
+Retrieves the current {ilm} ({ilm-init}) status.
 
 ==== Request
 
@@ -16,9 +16,9 @@ Retrieves the current {ilm} status.
 
 ==== Description
 
-Returns the status of the {ILM} plugin. The `operation_mode` field in the
+Returns the status of the {ilm-init} plugin. The `operation_mode` field in the
 response shows one of three states: `STARTED`, `STOPPING`,
-or `STOPPED`. You can change the status of the {ILM} plugin with the
+or `STOPPED`. You can change the status of the {ilm-init} plugin with the
 <<ilm-start, Start ILM>> and <<ilm-stop, Stop ILM>> APIs.
 
 ==== Request Parameters
@@ -32,7 +32,7 @@ For more information, see {stack-ov}/security-privileges.html[Security Privilege
 
 ==== Examples
 
-The following example gets the {ILM} plugin status.
+The following example gets the {ilm-init} plugin status.
 
 [source,js]
 --------------------------------------------------

docs/reference/ilm/apis/put-lifecycle.asciidoc

@@ -35,7 +35,7 @@ include::{docdir}/rest-api/timeoutparms.asciidoc[]
 
 You must have the `manage_ilm` cluster privilege to use this API. You must
 also have the `manage` index privilege on all indices being managed by `policy`.
-All operations executed by {Ilm} for a policy are executed as the user that
+All operations executed by {ilm} for a policy are executed as the user that
 put the latest version of a policy.
 For more information, see {stack-ov}/security-privileges.html[Security Privileges].
 

docs/reference/ilm/apis/start.asciidoc

@@ -1,14 +1,14 @@
 [role="xpack"]
 [testenv="basic"]
 [[ilm-start]]
-=== Start {ILM} API
+=== Start {ilm} API
 ++++
-<titleabbrev>Start {ILM}</titleabbrev>
+<titleabbrev>Start {ilm}</titleabbrev>
 ++++
 
 beta[]
 
-Start the {ILM} plugin.
+Start the {ilm} ({ilm-init}) plugin.
 
 ==== Request
 
@@ -16,9 +16,9 @@ Start the {ILM} plugin.
 
 ==== Description
 
-Starts the {ILM} plugin if it is currently stopped. {ILM} is started
-automatically when the cluster is formed. Restarting {ILM} is only
-necessary if it has been stopped using the <<ilm-stop, Stop {ILM} API>>.
+Starts the {ilm-init} plugin if it is currently stopped. {ilm-init} is started
+automatically when the cluster is formed. Restarting {ilm-init} is only
+necessary if it has been stopped using the <<ilm-stop, Stop {ilm-init} API>>.
 
 ==== Request Parameters
 
@@ -27,7 +27,7 @@ include::{docdir}/rest-api/timeoutparms.asciidoc[]
 ==== Authorization
 
 You must have the `manage_ilm` cluster privilege to use this API.
-For more information, see {stack-ov}/security-privileges.html[Security Privileges].
+For more information, see {stack-ov}/security-privileges.html[Security privileges].
 
 ==== Examples
 

docs/reference/ilm/apis/stop.asciidoc

@@ -1,14 +1,14 @@
 [role="xpack"]
 [testenv="basic"]
 [[ilm-stop]]
-=== Stop {ILM} API
+=== Stop {ilm} API
 ++++
-<titleabbrev>Stop {ILM}</titleabbrev>
+<titleabbrev>Stop {ilm}</titleabbrev>
 ++++
 
 beta[]
 
-Stop the {ILM} plugin.
+Stop the {ilm} ({ilm-init}) plugin.
 
 ==== Request
 
@@ -16,14 +16,14 @@ Stop the {ILM} plugin.
 
 ==== Description
 
-Halts all lifecycle management operations and stops the {ILM} plugin. This is
-useful when you are performing maintenance on the cluster and need to prevent
-{ILM} from performing any actions on your indices.
+Halts all lifecycle management operations and stops the {ilm-init} plugin. This
+is useful when you are performing maintenance on the cluster and need to prevent
+{ilm-init} from performing any actions on your indices.
 
 The API returns as soon as the stop request has been acknowledged, but the
 plugin might continue to run until in-progress operations complete and the plugin
 can be safely stopped. Use the  <<ilm-get-status, Get ILM Status>> API to see
-if {ILM} is running.
+if {ilm-init} is running.
 
 ==== Request Parameters
 

docs/reference/ilm/getting-started-ilm.asciidoc

@@ -5,8 +5,8 @@
 
 beta[]
 
-Let's jump into {ILM} by working through a hands-on scenario.
-This section will leverage many new concepts unique to {ILM} that
+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
 these in more details.
 
@@ -21,7 +21,7 @@ after 90 days.
 
 beta[]
 
-There are many new features introduced by {ILM}, but we will only focus on
+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
 policies are defined in JSON and include specific
@@ -99,7 +99,7 @@ PUT _template/datastream_template
 <3> alias to use for the rollover action, required since a rollover action is
     defined in the policy.
 
-The above index template introduces a few new settings specific to {ILM}.
+The above index template introduces a few new settings specific to {ilm-init}.
 The first being `index.lifecycle.name`. This setting will configure
 the "datastream_policy" to the index applying this template. This means
 that all newly created indices prefixed "datastream-" will be managed by
@@ -148,7 +148,7 @@ 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
-to {ILM}.
+to {ilm-init}.
 
 With the help of the <<ilm-explain-lifecycle,Explain API>>, we can know
 things like which phase we're in and when we entered that phase. The API
@@ -162,7 +162,7 @@ GET datastream-*/_ilm/explain
 // CONSOLE
 // TEST[continued]
 
-The above request will retrieve {ILM} execution information for all our
+The above request will retrieve {ilm-init} execution information for all our
 managed indices.
 
 
@@ -214,7 +214,7 @@ You can read about the full details of this response in the
 <<ilm-explain-lifecycle, explain API docs>>. For now, let's focus on how
 the response details which phase, action, and step we're in. We are in the
 "hot" phase, and "rollover" action. Rollover will continue to be called
-by {ILM} until its conditions are met and it rolls over the index.
+by {ilm-init} until its conditions are met and it rolls over the index.
 Afterwards, the original index will stay in the hot phase until 90 more
 days pass and it is deleted in the delete phase.
 As time goes on, new indices will be created and deleted.
@@ -226,7 +226,7 @@ that same alias.
 
 
 
-That's it! We have our first use-case managed by {ILM}.
+That's it! We have our first use-case managed by {ilm-init}.
 
 To learn more about all our APIs,
 check out <<index-lifecycle-management-api,ILM APIs>>.

docs/reference/ilm/index.asciidoc

@@ -3,17 +3,14 @@
 [[index-lifecycle-management]]
 = Managing the index lifecycle
 
-:ilm:             index lifecycle management
-:Ilm:             Index lifecycle management
-:ILM:             ILM
 [partintro]
 --
 beta[]
 
-The <<index-lifecycle-management-api, {ilm} (ILM) APIs>> enable you to automate how you
-want to manage your indices over time. Rather than simply performing management
-actions on your indices on a set schedule, you can base actions on other factors
-such as shard size and performance requirements.
+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
+performing management actions on your indices on a set schedule, you can base
+actions on other factors such as shard size and performance requirements.
 
 You control how indices are handled as they age by attaching a
 lifecycle policy to the index template used to create them. You can update

docs/reference/ilm/policy-definitions.asciidoc

@@ -71,8 +71,8 @@ index is rolled over, then `min_age` is the time elapsed from the time the index
 is rolled over. The intention here is to execute following phases and actions
 relative to when data was written last to a rolled over index.
 
-The previous phase's actions must complete before {ILM} will check `min_age` and
-transition into the next phase.
+The previous phase's actions must complete before {ilm} will check `min_age`
+and transition into the next phase.
 
 === Phase Execution
 
@@ -80,8 +80,8 @@ 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} actions are
-more complex and involve multiple operations against an index, each of these
+of discrete steps that are executed sequentially. Since some {ilm-init} actions
+are more complex and involve multiple operations against an index, each of these
 operations are done in isolation in a unit called a "step". The
 <<ilm-explain-lifecycle,Explain Lifecycle API>> exposes this information to us
 to see which step our index is either to execute next, or is currently

docs/reference/ilm/set-up-lifecycle-policy.asciidoc

@@ -6,9 +6,9 @@
 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 indexes.
+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
+indexes.
 
 [source,js]
 ------------------------
@@ -39,7 +39,7 @@ PUT _ilm/policy/my_policy
 
 {ilm} will manage an index using the policy defined in the
 `index.lifecycle.name` index setting. If this setting does not exist in the
-settings for a particular index {ilm} will not manage that index.
+settings for a particular index, {ilm} will not manage that index.
 
 To set the policy for an index there are two options:
 
@@ -90,7 +90,7 @@ PUT test-000001
 <1> Set this initial index to be the write index for this alias.
 
 We can now write data to the `test-alias` alias. Because we have a rollover
-action defined in our policy when the index grows larger than 25GB {ilm} will
+action defined in our policy, when the index grows larger than 25GB {ilm} will
 create a new index and roll the alias over to use the new index automatically.
 
 === Apply a policy to a create index request