Policies graduate to a dedicated doc guide

Author: michaelklishin

docs/ae.md

@@ -39,7 +39,7 @@ Alternate Exchange ("AE") is a feature that addresses these use cases.
 ## How to Define an Alternate Exchange {#define}
 
 For any given exchange except for the default one, an AE can be defined by clients using
-[policies](./parameters#policies). This is the recommended option
+[policies](./policies). This is the recommended option
 as policies are significantly simplify changes to such options (e.g. during
 upgrades).
 
@@ -79,7 +79,7 @@ rabbitmqctl.bat set_policy AE "^my-direct$" "{""alternate-exchange"":""my-ae""}"
 
 This will apply an AE of "my-ae" to the exchange called
 "my-direct". Policies can also be defined using the management
-plugin, see the [policy documentation](./parameters#policies) for more details.
+plugin, see the [policy documentation](./policies) for more details.
 
 
 

docs/classic-queues.md

@@ -38,7 +38,7 @@ Classic queues fully support [queue exclusivity](./queues),
 [queue length limits](./maxlength),
 [message priority](./priority),
 [consumer priority](./consumer-priority)
-and adhere to settings [controlled using policies](./parameters#policies).
+and adhere to settings [controlled using policies](./policies).
 
 Classic queues support [dead letter exchanges](./dlx) with
 the exception of [at-least-once dead-lettering](./quorum-queues#dead-lettering).

docs/consumers.md

@@ -617,7 +617,7 @@ the delivery is returned to the queue.
 
 ### SAC Cannot Be Enabled with a Policy
 
-The Single Active Consumer feature cannot be enabled with a [policy](./parameters#policies).
+The Single Active Consumer feature cannot be enabled with a [policy](./policies).
 Since policies in RabbitMQ are dynamic by nature, they can
 come and go, enabling and disabling the features they declare. Imagine suddenly
 disabling single active consumer on a queue: the broker would start sending messages to

docs/dlx.md

@@ -40,7 +40,7 @@ any of the usual types and are declared as normal.
 
 ## How Dead Lettering is Configured
 
-For any given queue, a DLX can be defined by clients using [policies](./parameters#policies). There
+For any given queue, a DLX can be defined by clients using [policies](./policies). There
 are several DLX-related policy keys, including some [only supported by quorum queues](./quorum-queues) but the two key ones are
 
  * `dead-letter-exchange`: The name of the DLX to use

docs/exchanges.md

@@ -230,18 +230,18 @@ pairs that can be provided by clients when a queue is declared.
 The map is used by certain features and exchange types, such as [alternate exchanges](#ae)
 and the headers exchanges.
 
-These optional arguments usually can be dynamically changed after queue declaration via [policies](./parameters#policies).
+These optional arguments usually can be dynamically changed after queue declaration via [policies](./policies).
 
 :::tip
 
-For keys that can be set via [policies](./parameters#policies), always first
+For keys that can be set via [policies](./policies), always first
 consider using a policy instead of setting these values in application code
 
 :::
 
 Optional exchange arguments can be set differently:
 
- * To groups of queues using [policies](./parameters#policies) (recommended)
+ * To groups of queues using [policies](./policies) (recommended)
  * On a per-exchange basis when a queue is declared by a client
 
 The former option is more flexible, non-intrusive, does not require application
@@ -257,10 +257,10 @@ declares queues.
 
 ### Optional Arguments and Policy-Defined Key Precedence {#optional-arguments-precedence}
 
-When the same key is provided by both client-provided `x-arguments` and by a [policy](./parameters#policies),
+When the same key is provided by both client-provided `x-arguments` and by a [policy](./policies),
 the former take precedence.
 
-However, if an [operator policy](./parameters#operator-policies) is also used, that will take precedence over the client-provided
+However, if an [operator policy](./policies#operator-policies) is also used, that will take precedence over the client-provided
 arguments, too. Operator policies are a protection mechanism and override client-provided values
 and user policy values.
 

docs/federated-exchanges/index.md

@@ -134,7 +134,7 @@ rabbitmqctl.bat set_parameter federation-upstream origin '"{""uri"":""amqp://rem
 More upstream definition parameters are covered in the [Federation Reference guide](./federation-reference).
 
 Once an upstream has been specified, a policy that controls federation can be added. It is added just like
-any other [policy](./parameters#policies), using:
+any other [policy](./policies), using:
 
 <Tabs groupId="shell-specific">
 <TabItem value="bash" label="bash" default>
@@ -166,7 +166,7 @@ the one with the highest priority will be used. Multiple policy definitions will
 priorities are equal.
 
 Once configured, a federation link (connection) will be opened for every matching exchange and upstream pair.
-By "matching exchange" here we mean an exchange that is matched by the [federation policy pattern](./parameters#policies).
+By "matching exchange" here we mean an exchange that is matched by the [federation policy pattern](./policies).
 If no exchanges matched, no links will be started.
 
 To deactivate federation for the matching exchanges, delete the policy using its name:

docs/federated-queues/index.md

@@ -143,7 +143,7 @@ rabbitmqctl.bat set_parameter federation-upstream origin '"{""uri"":""amqp://rem
 </Tabs>
 
 Once an upstream has been specified, a policy that controls federation can be added.
-It is added just like any other [policy](./parameters#policies), using `rabbitmqctl set_policy`:
+It is added just like any other [policy](./policies), using `rabbitmqctl set_policy`:
 
 <Tabs groupId="shell-specific">
 <TabItem value="bash" label="bash" default>
@@ -173,7 +173,7 @@ the one with the highest priority will be used. Multiple policy definitions will
 priorities are equal.
 
 Once configured, a federation link (connection) will be opened for every matching queue and upstream pair.
-By "matching queue" here we mean a queue that is matched by the [federation policy pattern](./parameters#policies).
+By "matching queue" here we mean a queue that is matched by the [federation policy pattern](./policies).
 If no queues matched, no links will be started.
 
 To deactivate federation for the matching queues, delete the policy using its name:

docs/federation-reference.md

@@ -58,7 +58,7 @@ rabbitmqctl set_policy federate-me '^federated\.' '{"federation-upstream":"up-1"
 
 Note that you cannot use the <code>federation-upstream</code>
 and <code>federation-upstream-set</code> keys together in a
-policy. For more detail on policies, see the <a href="./parameters#policies">policy</a> documentation.
+policy. For more detail on policies, see the <a href="/policies">policy</a> documentation.
 
 ### Upstreams {#upstreams}
 

docs/federation.md

@@ -102,7 +102,7 @@ Two steps are involved in setting up federation:
   to other nodes. This can be done via [runtime parameters](./parameters)
   or the [federation management plugin](https://github.com/rabbitmq/rabbitmq-federation-management) which
   adds a federation management tab to the [management UI](./management).
-* To enable federation, one or more [policies](./parameters#policies) that match exchanges or queues must be declared.
+* To enable federation, one or more [policies](./policies) that match exchanges or queues must be declared.
   The policy will make the matched objects (e.g. exchanges) federated, and one federation link
   (connection to other nodes) will be started for every match
 
@@ -132,7 +132,7 @@ are three levels of configuration involved in federation:
 
 * **Upstreams**: each [upstream](./federation-reference#upstreams) defines a remote connection endpoint.
 * **Upstream sets**: each [upstream set groups](./federation-reference#upstream-sets) together a set of upstreams to use for federation.
-* **Policies**: each [policy](./parameters#policies) selects a set of exchanges,
+* **Policies**: each [policy](./policies) selects a set of exchanges,
   queues or both, and applies a single upstream or an upstream
   set to those objects.
 
@@ -240,7 +240,7 @@ for the default one) with (implicit) low priority, and
 to federate them using the implicitly created upstream set
 "all", which includes our newly-created upstream.
 
-Any other [matching policy](./parameters#policies) with a priority greater than 0 will take
+Any other [matching policy](./policies) with a priority greater than 0 will take
 precedence over this policy. Keep in mind that `federate-me`
 is just a name we used for this example, you can use any
 string you want there.
@@ -517,7 +517,7 @@ Federation links are started when
 Therefore, in order to narrow down the problem, the recommended steps are:
 
  * Inspect federation upstreams
- * Inspect [policies](./parameters#policies), in particular looking for policies with conflicting [priorities](./parameters#policy-priorities)
+ * Inspect [policies](./policies), in particular looking for policies with conflicting [priorities](./policies#priorities)
  * Inspect [node logs](./logging)
 
 #### Inspect Federation Upstreams

docs/http-api-reference.md

@@ -1322,7 +1322,7 @@ curl -sL -u guest:guest -X DELETE -H "Accept: application/json" http://127.0.0.1
 
 ### GET /api/policies
 
-Lists [policies](./parameters#policies) across all virtual hosts in the cluster.
+Lists [policies](./policies) across all virtual hosts in the cluster.
 
 <Tabs groupId="examples">
 <TabItem value="rabbitmqadmin" label="rabbitmqadmin v2">
@@ -1339,7 +1339,7 @@ curl -sL -u guest:guest -H "Accept: application/json" http://127.0.0.1:15672/api
 
 ### GET /api/policies/\{_vhost_\}
 
-Lists [policies](./parameters#policies) in the given virtual host.
+Lists [policies](./policies) in the given virtual host.
 
 <Tabs groupId="examples">
 <TabItem value="curl" label="curl" default>
@@ -1352,11 +1352,11 @@ curl -sL -u guest:guest -H "Accept: application/json" http://127.0.0.1:15672/api
 
 ### GET /api/policies/\{_vhost_\}/\{_name_\}
 
-Returns a [policy](./parameters#policies) definition.
+Returns a [policy](./policies) definition.
 
 ### PUT /api/policies/\{_vhost_\}/\{_name_\}
 
-Declares or updates a [policy](./parameters#policies).
+Declares or updates a [policy](./policies).
 
 Example payload:
 
@@ -1371,7 +1371,7 @@ All the keys in the example are mandatory.
 Only one policy applies or a queue, stream or exchange at a time.
 
 When multiple policies have conflicting priorities, a random one will be applied.
-This scenario therefore [must be avoided](./parameters#how-policies-work).
+This scenario therefore [must be avoided](./policies#priorities).
 
 :::
 
@@ -1381,7 +1381,7 @@ Deletes a policy.
 
 ### GET /api/operator-policies
 
-Lists [operator policies](./parameters#operator-policies) across all virtual hosts in the cluster.
+Lists [operator policies](./policies#operator-policies) across all virtual hosts in the cluster.
 
 <Tabs groupId="examples">
 <TabItem value="rabbitmqadmin" label="rabbitmqadmin v2">
@@ -1398,7 +1398,7 @@ curl -sL -u guest:guest -H "Accept: application/json" http://127.0.0.1:15672/api
 
 ### GET /api/operator-policies/\{_vhost_\}
 
-Returns an operator [policy](./parameters#operator-policies) definition.
+Returns an operator [policy](./policies#operator-policies) definition.
 
 <Tabs groupId="examples">
 <TabItem value="curl" label="curl" default>
@@ -1411,7 +1411,7 @@ curl -sL -u guest:guest -H "Accept: application/json" http://127.0.0.1:15672/api
 
 ### GET /api/operator-policies/\{_vhost_\}/\{_name_\}
 
-Returns an operator [policy](./parameters#operator-policies) definition.
+Returns an operator [policy](./policies#operator-policies) definition.
 
 ### PUT /api/operator-policies/\{_vhost_\}/\{_name_\}
 
@@ -1429,7 +1429,7 @@ All the keys in the example are mandatory.
 Only one policy applies or a queue, stream or exchange at a time.
 
 When multiple policies have conflicting priorities, a random one will be applied.
-This scenario therefore [must be avoided](./parameters#how-policies-work).
+This scenario therefore [must be avoided](./policies#priorities).
 
 :::
 

docs/maxlength/index.md

@@ -26,11 +26,11 @@ You can set a maximum length on a [queue](./queues). The maximum length limit ca
 messages, or set to a number of bytes (the total of all message body lengths, ignoring message properties and any overheads), or both.
 
 To set the maximum length (of either type), you can
-define it using a [policy](./parameters#policies) (this option is highly recommended)
+define it using a [policy](./policies) (this option is highly recommended)
 or by clients using the [queue's optional arguments](./queues#optional-arguments).
 In a scenario where the maximum length is defined using both ways, that is, using a policy and using the arguments, then the minimum of the two values specified is used.
 
-Queue length settings configured using [operator policies](./parameters#operator-policies).
+Queue length settings configured using [operator policies](./policies#operator-policies).
 
 In all cases, the number of messages in the **ready** state are used. [Messages unacknowledged by consumers](./confirms)
 do not count towards the limit.
@@ -131,7 +131,7 @@ are sent `basic.nack` responses as long as the queue
 contains 2 messages and publisher confirms are enabled.
 
 Policies can also be defined using the management plugin, see
-the [policy documentation](./parameters#policies) for more details.
+the [policy documentation](./policies) for more details.
 
 
 ## Define Max Queue Length Using x-arguments During Declaration {#definition-using-x-args}
@@ -165,7 +165,7 @@ channel.queueDeclare("myqueue", false, false, false, args);
 ## Inspecting Queue Length Limits {#inspecting}
 
 To inspect effective limits for a queue, inspect its [optional arguments](./queues#optional-arguments) and
-[effective policy](./parameters#policies).
+[effective policy](./policies).
 
 This can be done using CLI tools or the management UI.