[DOCS] Adds information about freeze action and index priority to docs

docs/management/index-lifecycle-policies/create-policy.asciidoc

@@ -21,11 +21,13 @@ disable *Index Management*, then *Index Lifecycle Policies* is also disabled.
 [role="screenshot"]
 image::images/index-lifecycle-policies-create.png[][UI for creating an index lifecycle policy]
 
+==== Defining the phases of the index lifecycle
+
 You can define up to four phases in the index lifecycle. For each phase, you 
 can enable actions to optimize performance for that phase. Transitioning 
 between phases is based on the age of the index.
 
-The four phases of an index lifecycle policy are:
+The four phases in the index lifecycle are:
 
 * *Hot.* The index is actively being queried and written to. You can optionally 
 roll over to a new index when the 
@@ -35,8 +37,8 @@ index. You can still query the previous indices, but you only ever write to
 the “hot” index. See {ref}/indices-rollover-index.html[Rollover index] for more information.
 
 * *Warm.* The index is typically searched at a lower rate than when the data is 
-hot. The index is not used for storing for new data, but might occasionally add 
-late-arriving data, for example, from a Beat that had a network problem that's now fixed.  
+hot. The index is not used for storing new data, but might occasionally add 
+late-arriving data, for example, from a Beat with a network problem that's now fixed.  
 You can optionally shrink the number replicas and move the shards to a 
 different set of nodes with smaller or less performant hardware. You can also 
 reduce the number of primary shards and force merge the index into 
@@ -45,7 +47,10 @@ smaller {ref}/indices-segments.html[segments].
 * *Cold.* The index is no longer being updated and is seldom queried, but is 
 still searchable. If you have a big deployment, you can move it to even 
 less performant hardware. You might also reduce the number of replicas because 
-you expect the data to be queried less frequently.
+you expect the data to be queried less frequently. To keep the index searchable 
+for a longer period, and reduce the hardware requirements, you can use the 
+{ref}/frozen-indices.html[freeze action]. Queries are slower on a frozen index because the index is 
+reloaded from the disk to RAM on demand.
 
 * *Delete.* The index is no longer relevant. You can define when it is safe to 
 delete it.
@@ -55,3 +60,13 @@ delete phases are optional. For example, you might define all four phases for
 one policy and only a hot and delete phase for another.  See {ref}/_actions.html[Actions]
 for more information on the actions available in each phase. 
 
+==== Setting the index priority
+
+For the hot, warm, and cold phases, you can set a priority for recovering
+indices after a node restart. Indices with higher priorities are recovered 
+before indices with lower priorities. By default, the index priority is set to 
+100 in the hot phase, 50 in the warm phase, and 0 in the cold phase. 
+If the cold phase of one index has data that 
+is more important than the data in the hot phase of another, you might increase 
+the index priority in the cold phase.  See 
+{ref}/recovery-prioritization.html[Index recovery prioritization].