From 5dd192c75bc4500c54b7a9dddb295c5ecc1b8c10 Mon Sep 17 00:00:00 2001 From: Bilgin Ibryam Date: Tue, 21 May 2024 09:55:14 +0100 Subject: [PATCH 01/13] Fixes for: Wrong instructions in How to: Use the Multi-App Run template file #4153 --- .../multi-app-dapr-run/multi-app-template.md | 27 +++++++++++++++---- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-template.md b/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-template.md index e5c526da4..c37115311 100644 --- a/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-template.md +++ b/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-template.md @@ -1,6 +1,6 @@ --- type: docs -title: "How to: Use the Multi-App Run template file" +title: "q" linkTitle: "How to: Use the Multi-App Run template" weight: 2000 description: Unpack the Multi-App Run template file and its properties @@ -42,7 +42,7 @@ dapr run -f ```cmd -dapr run -f -k +dapr run -f -k ``` {{% /codetab %}} @@ -67,7 +67,7 @@ dapr run -f ./path/to/.yaml ```cmd -dapr run -f -k ./path/to/.yaml +dapr run -f ./path/to/.yaml -k ``` {{% /codetab %}} @@ -77,10 +77,27 @@ dapr run -f -k ./path/to/.yaml Once the multi-app template is running, you can view the started applications with the following command: +{{< tabs Self-hosted Kubernetes>}} + +{{% codetab %}} + + ```cmd dapr list ``` +{{% /codetab %}} + +{{% codetab %}} + + +```cmd +dapr list -k +``` +{{% /codetab %}} + +{{< /tabs >}} + ## Stop the multi-app template Stop the multi-app run template anytime with either of the following commands: @@ -109,12 +126,12 @@ dapr stop -f ./path/to/.yaml ```cmd # the template file needs to be called `dapr.yaml` by default if a directory path is given -dapr stop -f -k +dapr stop -f -k ``` or: ```cmd -dapr stop -f -k ./path/to/.yaml +dapr stop -f ./path/to/.yaml -k ``` {{% /codetab %}} From 893df1f841ee0675d25b92360db7c560ad8a7697 Mon Sep 17 00:00:00 2001 From: Bilgin Ibryam Date: Tue, 21 May 2024 09:59:42 +0100 Subject: [PATCH 02/13] Fixed acceidental title change --- .../local-development/multi-app-dapr-run/multi-app-template.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-template.md b/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-template.md index c37115311..606ae9fbe 100644 --- a/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-template.md +++ b/daprdocs/content/en/developing-applications/local-development/multi-app-dapr-run/multi-app-template.md @@ -1,6 +1,6 @@ --- type: docs -title: "q" +title: "How to: Use the Multi-App Run template file" linkTitle: "How to: Use the Multi-App Run template" weight: 2000 description: Unpack the Multi-App Run template file and its properties From 8129bd156d4c661ea194cd800729803da5e308d8 Mon Sep 17 00:00:00 2001 From: Tomas Ekeli Date: Thu, 30 May 2024 15:56:47 +0200 Subject: [PATCH 03/13] Describe queue-name, policy and dead-letter queue aspects Describe how to get past stumbling-blocks I met when setting up a service-bus queue pubsub. Signed-off-by: Tomas Ekeli --- .../supported-pubsub/setup-azure-servicebus-queues.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md index 57e3b9286..a8d07cd4f 100644 --- a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md +++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md @@ -181,6 +181,17 @@ When subscribing to a topic, you can configure `bulkSubscribe` options. Refer to Follow the instructions [here](https://learn.microsoft.com/azure/service-bus-messaging/service-bus-quickstart-portal) on setting up Azure Service Bus Queues. +{{% alert title="Note" color="primary" %}} +Your queue will need to have the same name as the Topic you are publishing to with Dapr. E.g. if you are publishing to the pubsb "myPubsub" on the topic "orders" your queue must be named "orders". +If you are using a Shared access policy to connect to the queue that policy must have the ability to "Manage" the queue. To work with a dead-letter queue the policy must live on the Service Bus Namespace that contains both the main queue and the dead-letter queue. +{{% /alert %}} + +### Retry policy and dead-letter queues + +An Azure ServiceBus Queue has a dead-letter quue by default. If you do not modify it the message will be retried the "Max delivery count" number of times (defaults to 10, can be set up to 2000). These retries will happen with very little delay before the message is put in the dead-letter queue. + +Since Dapr Pubsub has its own dead-letter queue -concept you can use this instead if you need control over retry-policy and you need to subscribe to the dead-letter queue (you probably should) you should set up a separate queue as that dead-letter queue in the same namespace, and a resilience component that defines how to retry on input. + ## Related links - [Basic schema for a Dapr component]({{< ref component-schema >}}) From e912c50d01d51550f9787c1fa20eaab4b876af52 Mon Sep 17 00:00:00 2001 From: Tomas Ekeli Date: Thu, 30 May 2024 16:02:04 +0200 Subject: [PATCH 04/13] Update setup-azure-servicebus-queues.md Signed-off-by: Tomas Ekeli --- .../supported-pubsub/setup-azure-servicebus-queues.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md index a8d07cd4f..ac428de2a 100644 --- a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md +++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md @@ -190,7 +190,7 @@ If you are using a Shared access policy to connect to the queue that policy must An Azure ServiceBus Queue has a dead-letter quue by default. If you do not modify it the message will be retried the "Max delivery count" number of times (defaults to 10, can be set up to 2000). These retries will happen with very little delay before the message is put in the dead-letter queue. -Since Dapr Pubsub has its own dead-letter queue -concept you can use this instead if you need control over retry-policy and you need to subscribe to the dead-letter queue (you probably should) you should set up a separate queue as that dead-letter queue in the same namespace, and a resilience component that defines how to retry on input. +Since Dapr Pubsub has its own dead-letter queue -concept you can use this instead if you need control over retry-policy and you need to subscribe to the dead-letter queue (you probably should). Set up a separate queue as that dead-letter queue in the same namespace, and a resilience component that defines how to retry on input. Then subscribe to that queue (topic) to get the failed messages and deal with them. ## Related links From b924132113ef153ffd7414bacdfb10f6650afbd3 Mon Sep 17 00:00:00 2001 From: Tomas Ekeli Date: Thu, 30 May 2024 16:12:06 +0200 Subject: [PATCH 05/13] Update setup-azure-servicebus-queues.md Signed-off-by: Tomas Ekeli --- .../supported-pubsub/setup-azure-servicebus-queues.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md index ac428de2a..7057c27c4 100644 --- a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md +++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md @@ -182,15 +182,15 @@ When subscribing to a topic, you can configure `bulkSubscribe` options. Refer to Follow the instructions [here](https://learn.microsoft.com/azure/service-bus-messaging/service-bus-quickstart-portal) on setting up Azure Service Bus Queues. {{% alert title="Note" color="primary" %}} -Your queue will need to have the same name as the Topic you are publishing to with Dapr. E.g. if you are publishing to the pubsb "myPubsub" on the topic "orders" your queue must be named "orders". +Your queue must have the same name as the Topic you are publishing to with Dapr. E.g. if you are publishing to the pubsb "myPubsub" on the topic "orders" your queue must be named "orders". If you are using a Shared access policy to connect to the queue that policy must have the ability to "Manage" the queue. To work with a dead-letter queue the policy must live on the Service Bus Namespace that contains both the main queue and the dead-letter queue. {{% /alert %}} ### Retry policy and dead-letter queues -An Azure ServiceBus Queue has a dead-letter quue by default. If you do not modify it the message will be retried the "Max delivery count" number of times (defaults to 10, can be set up to 2000). These retries will happen with very little delay before the message is put in the dead-letter queue. +An Azure ServiceBus Queue has a dead-letter queue by default. By default the messages are retried the "Max delivery count" number of times (defaults to 10, can be set up to 2000). These retries happen very rapidly and the message is put in the dead-letter queue if no success is returned. -Since Dapr Pubsub has its own dead-letter queue -concept you can use this instead if you need control over retry-policy and you need to subscribe to the dead-letter queue (you probably should). Set up a separate queue as that dead-letter queue in the same namespace, and a resilience component that defines how to retry on input. Then subscribe to that queue (topic) to get the failed messages and deal with them. +Dapr Pubsub has its own dead-letter queue -concept you can use instead. This lets you control the retry-policy and you can subscribe to the dead-letter queue through Dapr. Set up a separate queue as that dead-letter queue in the Azure Service Bus Namespace, and a resilience component that defines how to retry. You can subscribe to that (topic) to get the failed messages and deal with them. E.g. setting up a dead-letter queue `orders-dlq` in the subscription and a resilience lets your subscribe to the topic `orders-dlq` to handle failed messages. ## Related links From 1d91ccd727a5ddc4d0a7644920b6bd9a7f814f7d Mon Sep 17 00:00:00 2001 From: Tomas Ekeli Date: Fri, 31 May 2024 00:09:59 +0200 Subject: [PATCH 06/13] change resilience component to policy and link pubsub-deadletter Signed-off-by: Tomas Ekeli --- .../supported-pubsub/setup-azure-servicebus-queues.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md index 7057c27c4..fc6d95915 100644 --- a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md +++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md @@ -190,7 +190,9 @@ If you are using a Shared access policy to connect to the queue that policy must An Azure ServiceBus Queue has a dead-letter queue by default. By default the messages are retried the "Max delivery count" number of times (defaults to 10, can be set up to 2000). These retries happen very rapidly and the message is put in the dead-letter queue if no success is returned. -Dapr Pubsub has its own dead-letter queue -concept you can use instead. This lets you control the retry-policy and you can subscribe to the dead-letter queue through Dapr. Set up a separate queue as that dead-letter queue in the Azure Service Bus Namespace, and a resilience component that defines how to retry. You can subscribe to that (topic) to get the failed messages and deal with them. E.g. setting up a dead-letter queue `orders-dlq` in the subscription and a resilience lets your subscribe to the topic `orders-dlq` to handle failed messages. +Dapr Pubsub has its own dead-letter queue -concept you can use instead. This lets you control the retry-policy and you can subscribe to the dead-letter queue through Dapr. Set up a separate queue as that dead-letter queue in the Azure Service Bus Namespace, and a resilience policy that defines how to retry. You can subscribe to that (topic) to get the failed messages and deal with them. E.g. setting up a dead-letter queue `orders-dlq` in the subscription and a resilience lets your subscribe to the topic `orders-dlq` to handle failed messages. + +For more details on setting up dead-letter queues, see the [dead-letter article]({{< ref pubsub-deadletter >}}). ## Related links From db646a0ed77af44113b01e8c4b71e42aa7054bd6 Mon Sep 17 00:00:00 2001 From: Tomas Ekeli Date: Sun, 30 Jun 2024 20:28:46 +0200 Subject: [PATCH 07/13] Update daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md Co-authored-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> Signed-off-by: Tomas Ekeli --- .../supported-pubsub/setup-azure-servicebus-queues.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md index cb9a30954..20057ee35 100644 --- a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md +++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md @@ -190,7 +190,11 @@ If you are using a Shared access policy to connect to the queue that policy must An Azure ServiceBus Queue has a dead-letter queue by default. By default the messages are retried the "Max delivery count" number of times (defaults to 10, can be set up to 2000). These retries happen very rapidly and the message is put in the dead-letter queue if no success is returned. -Dapr Pubsub has its own dead-letter queue -concept you can use instead. This lets you control the retry-policy and you can subscribe to the dead-letter queue through Dapr. Set up a separate queue as that dead-letter queue in the Azure Service Bus Namespace, and a resilience policy that defines how to retry. You can subscribe to that (topic) to get the failed messages and deal with them. E.g. setting up a dead-letter queue `orders-dlq` in the subscription and a resilience lets your subscribe to the topic `orders-dlq` to handle failed messages. +Dapr Pub/sub offers its own dead-letter queue concept that lets you control the retry policy and subscribe to the dead-letter queue through Dapr. +1. Set up a separate queue as that dead-letter queue in the Azure Service Bus namespace, and a resilience policy that defines how to retry. +1. Subscribe to the topic to get the failed messages and deal with them. + +For example, setting up a dead-letter queue `orders-dlq` in the subscription and a resiliency policy lets you subscribe to the topic `orders-dlq` to handle failed messages. For more details on setting up dead-letter queues, see the [dead-letter article]({{< ref pubsub-deadletter >}}). From 1fed5a0922469f9a33f88b953d55b90f93e5d1ab Mon Sep 17 00:00:00 2001 From: Tomas Ekeli Date: Sun, 30 Jun 2024 20:28:57 +0200 Subject: [PATCH 08/13] Update daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md Co-authored-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> Signed-off-by: Tomas Ekeli --- .../supported-pubsub/setup-azure-servicebus-queues.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md index 20057ee35..fe25df682 100644 --- a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md +++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md @@ -183,7 +183,7 @@ Follow the instructions [here](https://learn.microsoft.com/azure/service-bus-mes {{% alert title="Note" color="primary" %}} Your queue must have the same name as the Topic you are publishing to with Dapr. E.g. if you are publishing to the pubsb "myPubsub" on the topic "orders" your queue must be named "orders". -If you are using a Shared access policy to connect to the queue that policy must have the ability to "Manage" the queue. To work with a dead-letter queue the policy must live on the Service Bus Namespace that contains both the main queue and the dead-letter queue. +If you are using a shared access policy to connect to the queue, that policy must be able to "manage" the queue. To work with a dead-letter queue, the policy must live on the Service Bus Namespace that contains both the main queue and the dead-letter queue. {{% /alert %}} ### Retry policy and dead-letter queues From 74a87a7c3f62717328df9bfe5f1a670059881889 Mon Sep 17 00:00:00 2001 From: Tomas Ekeli Date: Sun, 30 Jun 2024 20:29:05 +0200 Subject: [PATCH 09/13] Update daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md Co-authored-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> Signed-off-by: Tomas Ekeli --- .../supported-pubsub/setup-azure-servicebus-queues.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md index fe25df682..baf093625 100644 --- a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md +++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md @@ -182,7 +182,7 @@ When subscribing to a topic, you can configure `bulkSubscribe` options. Refer to Follow the instructions [here](https://learn.microsoft.com/azure/service-bus-messaging/service-bus-quickstart-portal) on setting up Azure Service Bus Queues. {{% alert title="Note" color="primary" %}} -Your queue must have the same name as the Topic you are publishing to with Dapr. E.g. if you are publishing to the pubsb "myPubsub" on the topic "orders" your queue must be named "orders". +Your queue must have the same name as the topic you are publishing to with Dapr. For example, if you are publishing to the pub/sub `"myPubsub"` on the topic `"orders"`, your queue must be named `"orders"`. If you are using a shared access policy to connect to the queue, that policy must be able to "manage" the queue. To work with a dead-letter queue, the policy must live on the Service Bus Namespace that contains both the main queue and the dead-letter queue. {{% /alert %}} From b7587634afd7e2c82e601bcba0c50ff568f1b54d Mon Sep 17 00:00:00 2001 From: Tomas Ekeli Date: Sun, 30 Jun 2024 20:29:13 +0200 Subject: [PATCH 10/13] Update daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md Co-authored-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> Signed-off-by: Tomas Ekeli --- .../supported-pubsub/setup-azure-servicebus-queues.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md index baf093625..2bc7ca5f9 100644 --- a/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md +++ b/daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md @@ -188,7 +188,7 @@ If you are using a shared access policy to connect to the queue, that policy mus ### Retry policy and dead-letter queues -An Azure ServiceBus Queue has a dead-letter queue by default. By default the messages are retried the "Max delivery count" number of times (defaults to 10, can be set up to 2000). These retries happen very rapidly and the message is put in the dead-letter queue if no success is returned. +By default, an Azure Service Bus Queue has a dead-letter queue. The messages are retried the amount given for `maxDeliveryCount`. The default `maxDeliveryCount` value defaults to 10, but can be set up to 2000. These retries happen very rapidly and the message is put in the dead-letter queue if no success is returned. Dapr Pub/sub offers its own dead-letter queue concept that lets you control the retry policy and subscribe to the dead-letter queue through Dapr. 1. Set up a separate queue as that dead-letter queue in the Azure Service Bus namespace, and a resilience policy that defines how to retry. From b5c0754d9aeeb68ce7e45cb51176c816643e8ec2 Mon Sep 17 00:00:00 2001 From: ibandhiya Date: Tue, 16 Jul 2024 19:55:17 +0530 Subject: [PATCH 11/13] Update service-mesh.md (#4261) ref link added for distributed tracing Signed-off-by: ibandhiya --- daprdocs/content/en/concepts/service-mesh.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/concepts/service-mesh.md b/daprdocs/content/en/concepts/service-mesh.md index 0e3c4cf9e..d0f686dc3 100644 --- a/daprdocs/content/en/concepts/service-mesh.md +++ b/daprdocs/content/en/concepts/service-mesh.md @@ -7,7 +7,7 @@ description: > How Dapr compares to and works with service meshes --- -Dapr uses a sidecar architecture, running as a separate process alongside the application and includes features such as service invocation, network security, and distributed tracing. This often raises the question: how does Dapr compare to service mesh solutions such as [Linkerd](https://linkerd.io/), [Istio](https://istio.io/) and [Open Service Mesh](https://openservicemesh.io/) among others? +Dapr uses a sidecar architecture, running as a separate process alongside the application and includes features such as service invocation, network security, and [distributed tracing](https://middleware.io/blog/what-is-distributed-tracing/). This often raises the question: how does Dapr compare to service mesh solutions such as [Linkerd](https://linkerd.io/), [Istio](https://istio.io/) and [Open Service Mesh](https://openservicemesh.io/) among others? ## How Dapr and service meshes compare While Dapr and service meshes do offer some overlapping capabilities, **Dapr is not a service mesh**, where a service mesh is defined as a *networking* service mesh. Unlike a service mesh which is focused on networking concerns, Dapr is focused on providing building blocks that make it easier for developers to build applications as microservices. Dapr is developer-centric, versus service meshes which are infrastructure-centric. From 4fe1ded85e5cf57a4badf02bdf3065a57836fd1c Mon Sep 17 00:00:00 2001 From: Bilgin Ibryam Date: Wed, 17 Jul 2024 20:02:56 +0100 Subject: [PATCH 12/13] Replaced wrong resiliency example definition --- .../resiliency/resiliency-state-quickstart.md | 23 ++++++++++--------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md index 8a35d2442..674cb5dae 100644 --- a/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md +++ b/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-state-quickstart.md @@ -61,27 +61,28 @@ Run the `order-processor` service alongside a Dapr sidecar. The Dapr sidecar the metadata: name: myresiliency scopes: - - checkout - + - order-processor + spec: policies: retries: retryForever: policy: constant - maxInterval: 5s - maxRetries: -1 - + duration: 5s + maxRetries: -1 + circuitBreakers: simpleCB: maxRequests: 1 - timeout: 5s + timeout: 5s trip: consecutiveFailures >= 5 - + targets: - apps: - order-processor: - retry: retryForever - circuitBreaker: simpleCB + components: + statestore: + outbound: + retry: retryForever + circuitBreaker: simpleCB ``` From 32fce1da8ff8ed03fae3bdfad73e4092f3c5042a Mon Sep 17 00:00:00 2001 From: Bilgin Ibryam Date: Fri, 19 Jul 2024 22:42:27 +0100 Subject: [PATCH 13/13] Fixed typo in links (#4267) --- .../building-blocks/secrets/secrets-scopes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-scopes.md b/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-scopes.md index 167d85f98..afd417515 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-scopes.md +++ b/daprdocs/content/en/developing-applications/building-blocks/secrets/secrets-scopes.md @@ -69,7 +69,7 @@ spec: allowedSecrets: ["secret1", "secret2"] ``` -The default access to the `vault` secret store is `deny`, while some secrets are accessible by the application, based on the `allowedSecrets` list. [Learn how to apply configuration to the sidecar]]({{< ref configuration-concept.md >}}). +The default access to the `vault` secret store is `deny`, while some secrets are accessible by the application, based on the `allowedSecrets` list. [Learn how to apply configuration to the sidecar]({{< ref configuration-concept.md >}}). ## Scenario 3: Deny access to certain sensitive secrets in a secret store @@ -88,7 +88,7 @@ spec: deniedSecrets: ["secret1", "secret2"] ``` -This example configuration explicitly denies access to `secret1` and `secret2` from the secret store named `vault` while allowing access to all other secrets. [Learn how to apply configuration to the sidecar]]({{< ref configuration-concept.md >}}). +This example configuration explicitly denies access to `secret1` and `secret2` from the secret store named `vault` while allowing access to all other secrets. [Learn how to apply configuration to the sidecar]({{< ref configuration-concept.md >}}). ## Permission priority