Merge branch 'v1.13' into issue_4059

daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-overview.md

@@ -41,7 +41,7 @@ Applications can also use the secrets API to access secrets from a Kubernetes se
 - The Helm defaults, or
 - `dapr init -k`
 
-If you are using another secret store, you can disable (not configure) the Dapr Kubernetes secret store by setting `disable-builtin-k8s-secret-store` to `true` through the Helm settings. The default is `false`.
+If you are using another secret store, you can disable (not configure) the Dapr Kubernetes secret store by adding the annotation `dapr.io/disable-builtin-k8s-secret-store: "true"` to the deployment.yaml file. The default is `false`.
 
 In the example below, the application retrieves the same secret "mysecret" from a Kubernetes secret store.
 
@@ -86,4 +86,4 @@ Want to skip the quickstarts? Not a problem. You can try out the secret manageme
 ## Next steps
 
 - Learn [how to use secret scoping]({{< ref secrets-scopes.md >}}).
-- Read the [secrets API reference doc]({{< ref secrets_api.md >}}).
+- Read the [secrets API reference doc]({{< ref secrets_api.md >}}).

daprdocs/content/en/operations/hosting/kubernetes/kubernetes-upgrade.md

@@ -49,7 +49,7 @@ The CustomResourceDefinition "configurations.dapr.io" is invalid: spec.preserveU
 1. Run the following command to upgrade the `CustomResourceDefinition` to a compatible version:
 
     ```sh
-    kubectl replace -f https://raw.githubusercontent.com/dapr/dapr/5a15b3e0f093d2d0938b12f144c7047474a290fe/charts/dapr/crds/configuration.yaml
+    kubectl replace -f https://raw.githubusercontent.com/dapr/dapr/release-{{% dapr-latest-version short="true" %}}/charts/dapr/crds/configuration.yaml
     ```
 
 1. Proceed with the `dapr upgrade --runtime-version {{% dapr-latest-version long="true" %}} -k` command.

daprdocs/content/en/reference/components-reference/supported-pubsub/setup-rabbitmq.md

@@ -207,9 +207,15 @@ For example, if installing using the example above, the RabbitMQ server client a
 
 ## Use topic exchange to route messages
 
-Setting `exchangeKind` to `"topic"` uses the topic exchanges, which are commonly used for the multicast routing of messages.
+Setting `exchangeKind` to `"topic"` uses the topic exchanges, which are commonly used for the multicast routing of messages. In order to route messages using topic exchange, you must set the following metadata:
-Messages with a `routing key` will be routed to one or many queues based on the `routing key` defined in the metadata when subscribing.
+
-The routing key is defined by the `routingKey` metadata. For example, if an app is configured with a routing key `keyA`:
+- **`routingKey`:**  
+   Messages with a routing key are routed to one or many queues based on the `routing key` defined in the metadata when subscribing.
+
+- **`queueName`:**  
+   If you don't set the `queueName`, only one queue is created, and all routing keys will route to that queue. This means all subscribers will bind to that queue, which won't give the desired results.
+
+For example, if an app is configured with a routing key `keyA` and `queueName` of `queue-A`:
 
 ```yaml
 apiVersion: dapr.io/v2alpha1
@@ -223,6 +229,7 @@ spec:
   pubsubname: pubsub
   metadata:
     routingKey: keyA
+    queueName: queue-A
 ```
 
 It will receive messages with routing key `keyA`, and messages with other routing keys are not received.