diff --git a/daprdocs/content/en/concepts/overview.md b/daprdocs/content/en/concepts/overview.md index 23123024c13..3184fb3d330 100644 --- a/daprdocs/content/en/concepts/overview.md +++ b/daprdocs/content/en/concepts/overview.md @@ -139,7 +139,7 @@ Dapr can be used from any developer framework. Here are some that have been inte | [.NET]({{< ref dotnet >}}) | [ASP.NET Core](https://github.com/dapr/dotnet-sdk/tree/master/examples/AspNetCore) | Brings stateful routing controllers that respond to pub/sub events from other services. Can also take advantage of [ASP.NET Core gRPC Services](https://docs.microsoft.com/aspnet/core/grpc/). | [Java]({{< ref java >}}) | [Spring Boot](https://spring.io/) | Build Spring boot applications with Dapr APIs | [Python]({{< ref python >}}) | [Flask]({{< ref python-flask.md >}}) | Build Flask applications with Dapr APIs -| [Javascript](https://github.com/dapr/js-sdk) | [Express](http://expressjs.com/) | Build Express applications with Dapr APIs +| [JavaScript](https://github.com/dapr/js-sdk) | [Express](http://expressjs.com/) | Build Express applications with Dapr APIs | [PHP]({{< ref php >}}) | | You can serve with Apache, Nginx, or Caddyserver. #### Integrations and extensions diff --git a/daprdocs/content/en/developing-applications/building-blocks/bindings/howto-bindings.md b/daprdocs/content/en/developing-applications/building-blocks/bindings/howto-bindings.md index 1822f543a6d..02df63c2078 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/bindings/howto-bindings.md +++ b/daprdocs/content/en/developing-applications/building-blocks/bindings/howto-bindings.md @@ -106,7 +106,7 @@ spec: The code examples below leverage Dapr SDKs to invoke the output bindings endpoint on a running Dapr instance. -{{< tabs Dotnet Java Python Go JavaScript>}} +{{< tabs ".NET" Java Python Go JavaScript>}} {{% codetab %}} diff --git a/daprdocs/content/en/developing-applications/building-blocks/bindings/howto-triggers.md b/daprdocs/content/en/developing-applications/building-blocks/bindings/howto-triggers.md index 70320818a3e..4a5f6d4dd7f 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/bindings/howto-triggers.md +++ b/daprdocs/content/en/developing-applications/building-blocks/bindings/howto-triggers.md @@ -115,7 +115,7 @@ Configure your application to receive incoming events. If you're using HTTP, you Below are code examples that leverage Dapr SDKs to demonstrate an output binding. -{{< tabs Dotnet Java Python Go JavaScript>}} +{{< tabs ".NET" Java Python Go JavaScript>}} {{% codetab %}} diff --git a/daprdocs/content/en/developing-applications/building-blocks/configuration/howto-manage-configuration.md b/daprdocs/content/en/developing-applications/building-blocks/configuration/howto-manage-configuration.md index 6fba434ad7d..25d4169e20f 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/configuration/howto-manage-configuration.md +++ b/daprdocs/content/en/developing-applications/building-blocks/configuration/howto-manage-configuration.md @@ -71,7 +71,7 @@ spec: The following example shows how to get a saved configuration item using the Dapr Configuration API. -{{< tabs ".NET" Java Python Go Javascript "HTTP API (BASH)" "HTTP API (Powershell)">}} +{{< tabs ".NET" Java Python Go JavaScript "HTTP API (BASH)" "HTTP API (Powershell)">}} {{% codetab %}} @@ -252,7 +252,7 @@ Invoke-RestMethod -Uri 'http://localhost:3601/v1.0/configuration/configstore?key Below are code examples that leverage SDKs to subscribe to keys `[orderId1, orderId2]` using `configstore` store component. -{{< tabs ".NET" "ASP.NET Core" Java Python Go Javascript>}} +{{< tabs ".NET" "ASP.NET Core" Java Python Go JavaScript>}} {{% codetab %}} @@ -521,7 +521,7 @@ After you've subscribed to watch configuration items, you will receive updates f Following are the code examples showing how you can unsubscribe to configuration updates using unsubscribe API. -{{< tabs ".NET" Java Python Go Javascript "HTTP API (BASH)" "HTTP API (Powershell)">}} +{{< tabs ".NET" Java Python Go JavaScript "HTTP API (BASH)" "HTTP API (Powershell)">}} {{% codetab %}} ```csharp diff --git a/daprdocs/content/en/developing-applications/building-blocks/distributed-lock/howto-use-distributed-lock.md b/daprdocs/content/en/developing-applications/building-blocks/distributed-lock/howto-use-distributed-lock.md index 4a2745c3484..5165e5af05d 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/distributed-lock/howto-use-distributed-lock.md +++ b/daprdocs/content/en/developing-applications/building-blocks/distributed-lock/howto-use-distributed-lock.md @@ -41,7 +41,7 @@ spec: ### Acquire lock -{{< tabs HTTP Dotnet Go >}} +{{< tabs HTTP ".NET" Go >}} {{% codetab %}} @@ -122,7 +122,7 @@ func main() { ### Unlock existing lock -{{< tabs HTTP Dotnet Go >}} +{{< tabs HTTP ".NET" Go >}} {{% codetab %}} diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-publish-subscribe.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-publish-subscribe.md index c030505b71e..86e8f2491fa 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-publish-subscribe.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-publish-subscribe.md @@ -65,7 +65,7 @@ scopes: You can override this file with another [pubsub component]({{< ref setup-pubsub >}}) by creating a components directory (in this example, `myComponents`) containing the file and using the flag `--resources-path` with the `dapr run` CLI command. -{{< tabs Dotnet Java Python Go Javascript >}} +{{< tabs ".NET" Java Python Go JavaScript >}} {{% codetab %}} @@ -194,7 +194,7 @@ To prevent reprocessing or loss of unprocessed messages, in-flight messages betw Below are code examples that leverage Dapr SDKs to subscribe to the topic you defined in `subscription.yaml`. -{{< tabs Dotnet Java Python Go JavaScript>}} +{{< tabs ".NET" Java Python Go JavaScript>}} {{% codetab %}} @@ -430,7 +430,7 @@ Invoke-RestMethod -Method Post -ContentType 'application/json' -Body '{"orderId" Below are code examples that leverage Dapr SDKs to publish a topic. -{{< tabs Dotnet Java Python Go Javascript>}} +{{< tabs ".NET" Java Python Go JavaScript>}} {{% codetab %}} diff --git a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md index 2406c9a39a9..89ca63fe8ca 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md +++ b/daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-bulk.md @@ -22,7 +22,7 @@ The bulk publish operation also does not guarantee any ordering of messages. ### Example -{{< tabs Java Javascript Dotnet Python Go "HTTP API (Bash)" "HTTP API (PowerShell)" >}} +{{< tabs Java JavaScript ".NET" Python Go "HTTP API (Bash)" "HTTP API (PowerShell)" >}} {{% codetab %}} diff --git a/daprdocs/content/en/developing-applications/building-blocks/secrets/howto-secrets.md b/daprdocs/content/en/developing-applications/building-blocks/secrets/howto-secrets.md index 470693f5f2f..d45be463684 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/secrets/howto-secrets.md +++ b/daprdocs/content/en/developing-applications/building-blocks/secrets/howto-secrets.md @@ -71,7 +71,7 @@ See a [full API reference]({{< ref secrets_api.md >}}). Now that you've set up the local secret store, call Dapr to get the secrets from your application code. Below are code examples that leverage Dapr SDKs for retrieving a secret. -{{< tabs Dotnet Java Python Go Javascript>}} +{{< tabs ".NET" Java Python Go JavaScript>}} {{% codetab %}} diff --git a/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-discover-services.md b/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-discover-services.md index c3f78e4a4e0..301c1542be9 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-discover-services.md +++ b/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-discover-services.md @@ -24,7 +24,7 @@ Dapr allows you to assign a global, unique ID for your app. This ID encapsulates {{% codetab %}} ```bash -dapr run --app-id checkout --app-protocol http --dapr-http-port 3500 -- python3 checkout/app.py +dapr run --app-id checkout --app-protocol http --dapr-http-port 3500 -- python3 checkout/app.py dapr run --app-id order-processor --app-port 8001 --app-protocol http --dapr-http-port 3501 -- python3 order-processor/app.py ``` @@ -32,7 +32,7 @@ dapr run --app-id order-processor --app-port 8001 --app-protocol http --dapr-ht If your app uses a TLS, you can tell Dapr to invoke your app over a TLS connection by setting `--app-protocol https`: ```bash -dapr run --app-id checkout --app-protocol https --dapr-http-port 3500 -- python3 checkout/app.py +dapr run --app-id checkout --app-protocol https --dapr-http-port 3500 -- python3 checkout/app.py dapr run --app-id order-processor --app-port 8001 --app-protocol https --dapr-http-port 3501 -- python3 order-processor/app.py ``` @@ -42,7 +42,7 @@ dapr run --app-id order-processor --app-port 8001 --app-protocol https --dapr-ht {{% codetab %}} ```bash -dapr run --app-id checkout --app-protocol http --dapr-http-port 3500 -- npm start +dapr run --app-id checkout --app-protocol http --dapr-http-port 3500 -- npm start dapr run --app-id order-processor --app-port 5001 --app-protocol http --dapr-http-port 3501 -- npm start ``` @@ -50,7 +50,7 @@ dapr run --app-id order-processor --app-port 5001 --app-protocol http --dapr-ht If your app uses a TLS, you can tell Dapr to invoke your app over a TLS connection by setting `--app-protocol https`: ```bash -dapr run --app-id checkout --dapr-http-port 3500 --app-protocol https -- npm start +dapr run --app-id checkout --dapr-http-port 3500 --app-protocol https -- npm start dapr run --app-id order-processor --app-port 5001 --dapr-http-port 3501 --app-protocol https -- npm start ``` @@ -60,7 +60,7 @@ dapr run --app-id order-processor --app-port 5001 --dapr-http-port 3501 --app-pr {{% codetab %}} ```bash -dapr run --app-id checkout --app-protocol http --dapr-http-port 3500 -- dotnet run +dapr run --app-id checkout --app-protocol http --dapr-http-port 3500 -- dotnet run dapr run --app-id order-processor --app-port 7001 --app-protocol http --dapr-http-port 3501 -- dotnet run ``` @@ -68,7 +68,7 @@ dapr run --app-id order-processor --app-port 7001 --app-protocol http --dapr-htt If your app uses a TLS, you can tell Dapr to invoke your app over a TLS connection by setting `--app-protocol https`: ```bash -dapr run --app-id checkout --dapr-http-port 3500 --app-protocol https -- dotnet run +dapr run --app-id checkout --dapr-http-port 3500 --app-protocol https -- dotnet run dapr run --app-id order-processor --app-port 7001 --dapr-http-port 3501 --app-protocol https -- dotnet run ``` @@ -247,7 +247,9 @@ namespace EventService var content = new StringContent(orderJson, Encoding.UTF8, "application/json"); var httpClient = DaprClient.CreateInvokeHttpClient(); - await httpClient.PostAsJsonAsync($"http://order-processor/orders", content); + var response = await httpClient.PostAsJsonAsync("http://order-processor/orders", content); + var result = await response.Content.ReadAsStringAsync(); + Console.WriteLine("Order requested: " + orderId); Console.WriteLine("Result: " + result); } @@ -408,6 +410,14 @@ Using CLI: dapr invoke --app-id checkout --method checkout/100 ``` +#### Including a query string in the URL + +You can also append a query string or a fragment to the end of the URL and Dapr will pass it through unchanged. This means that if you need to pass some additional arguments in your service invocation that aren't part of a payload or the path, you can do so by appending a `?` to the end of the URL, followed by the key/value pairs separated by `=` signs and delimited by `&`. For example: + +```bash +curl 'http://dapr-app-id:checkout@localhost:3602/checkout/100?basket=1234&key=abc` -X POST +``` + ### Namespaces When running on [namespace supported platforms]({{< ref "service_invocation_api.md#namespace-supported-platforms" >}}), you include the namespace of the target app in the app ID. For example, following the `.` format, use `checkout.production`. diff --git a/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-services-grpc.md b/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-services-grpc.md index 1de970c7d1f..71679ff519a 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-services-grpc.md +++ b/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-services-grpc.md @@ -126,7 +126,7 @@ ctx = metadata.AppendToOutgoingContext(ctx, "dapr-app-id", "server") All languages supported by gRPC allow for adding metadata. Here are a few examples: -{{< tabs Java Dotnet Python JavaScript Ruby "C++">}} +{{< tabs Java ".NET" Python JavaScript Ruby "C++">}} {{% codetab %}} ```java @@ -249,7 +249,7 @@ When using Dapr to proxy streaming RPC calls using gRPC, you must set an additio For example: -{{< tabs Go Java Dotnet Python JavaScript Ruby "C++">}} +{{< tabs Go Java ".NET" Python JavaScript Ruby "C++">}} {{% codetab %}} ```go diff --git a/daprdocs/content/en/developing-applications/building-blocks/state-management/howto-get-save-state.md b/daprdocs/content/en/developing-applications/building-blocks/state-management/howto-get-save-state.md index fd492d188b6..6a6c27d4bf5 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/state-management/howto-get-save-state.md +++ b/daprdocs/content/en/developing-applications/building-blocks/state-management/howto-get-save-state.md @@ -68,7 +68,7 @@ Set an `app-id`, as the state keys are prefixed with this value. If you don't se The following example shows how to save and retrieve a single key/value pair using the Dapr state management API. -{{< tabs Dotnet Java Python Go Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}} +{{< tabs ".NET" Java Python Go JavaScript "HTTP API (Bash)" "HTTP API (PowerShell)">}} {{% codetab %}} @@ -356,7 +356,7 @@ Restart your sidecar and try retrieving state again to observe that state persis Below are code examples that leverage Dapr SDKs for deleting the state. -{{< tabs Dotnet Java Python Go Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}} +{{< tabs ".NET" Java Python Go JavaScript "HTTP API (Bash)" "HTTP API (PowerShell)">}} {{% codetab %}} @@ -537,7 +537,7 @@ Try getting state again. Note that no value is returned. Below are code examples that leverage Dapr SDKs for saving and retrieving multiple states. -{{< tabs Dotnet Java Python Go Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}} +{{< tabs ".NET" Java Python Go JavaScript "HTTP API (Bash)" "HTTP API (PowerShell)">}} {{% codetab %}} @@ -788,7 +788,7 @@ State transactions require a state store that supports multi-item transactions. Below are code examples that leverage Dapr SDKs for performing state transactions. -{{< tabs Dotnet Java Python Go Javascript "HTTP API (Bash)" "HTTP API (PowerShell)">}} +{{< tabs ".NET" Java Python Go JavaScript "HTTP API (Bash)" "HTTP API (PowerShell)">}} {{% codetab %}} diff --git a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-features-concepts.md b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-features-concepts.md index 3ad667701f0..efdac157ce6 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-features-concepts.md +++ b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-features-concepts.md @@ -48,7 +48,7 @@ This "replay" behavior continues until the workflow function completes or fails Using this replay technique, a workflow is able to resume execution from any "await" point as if it had never been unloaded from memory. Even the values of local variables from previous runs can be restored without the workflow engine knowing anything about what data they stored. This ability to restore state makes Dapr Workflows _durable_ and _fault tolerant_. {{% alert title="Note" color="primary" %}} -The workflow replay behavior described here requires that workflow function code be _deterministic_. Deterministic workflow functions take the exact same actions when provided the exact same inputs. [Learn more about the limitations around deterministic workflow code.]({{< ref "workflow-features-concepts.md#workflow-determinism-and-code-constraints" >}}) +The workflow replay behavior described here requires that workflow function code be _deterministic_. Deterministic workflow functions take the exact same actions when provided the exact same inputs. [Learn more about the limitations around deterministic workflow code.]({{< ref "workflow-features-concepts.md#workflow-determinism-and-code-restraints" >}}) {{% /alert %}} @@ -75,9 +75,9 @@ You can use the following two techniques to write workflows that may need to sch ### Updating workflow code -Because workflows are long-running and durable, updating workflow code must be done with extreme care. As discussed in the [workflow determinism]({{< ref "#workflow-determinism-and-code-constraints" >}}) limitation section, workflow code must be deterministic. Updates to workflow code must preserve this determinism if there are any non-completed workflow instances in the system. Otherwise, updates to workflow code can result in runtime failures the next time those workflows execute. +Because workflows are long-running and durable, updating workflow code must be done with extreme care. As discussed in the [workflow determinism]({{< ref "#workflow-determinism-and-code-restraints" >}}) limitation section, workflow code must be deterministic. Updates to workflow code must preserve this determinism if there are any non-completed workflow instances in the system. Otherwise, updates to workflow code can result in runtime failures the next time those workflows execute. -[See known limitations]({{< ref "workflow-features-concepts.md#workflow-determinism-and-code-constraints" >}}) +[See known limitations]({{< ref "#limitations" >}}) ## Workflow activities @@ -123,7 +123,7 @@ Retries are internally implemented using durable timers. This means that workflo The actions performed by a retry policy are saved into a workflow's history. Care must be taken not to change the behavior of a retry policy after a workflow has already been executed. Otherwise, the workflow may behave unexpectedly when replayed. See the notes on [updating workflow code]({{< ref "#updating-workflow-code" >}}) for more information. {{% /alert %}} -It's possible to use both workflow retry policies and Dapr Resiliency policies together. For example, if a workflow activity uses a Dapr client to invoke a service, the Dapr client uses the configured resiliency policy. See [Quickstart: Service-to-service resiliency]({{< ref "#resiliency-serviceinvo-quickstart" >}}) for more information with an example. However, if the activity itself fails for any reason, including exhausting the retries on the resiliency policy, then the workflow's resiliency policy kicks in. +It's possible to use both workflow retry policies and Dapr Resiliency policies together. For example, if a workflow activity uses a Dapr client to invoke a service, the Dapr client uses the configured resiliency policy. See [Quickstart: Service-to-service resiliency]({{< ref "resiliency-serviceinvo-quickstart.md" >}}) for more information with an example. However, if the activity itself fails for any reason, including exhausting the retries on the resiliency policy, then the workflow's resiliency policy kicks in. {{% alert title="Note" color="primary" %}} Using workflow retry policies and resiliency policies together can result in unexpected behavior. For example, if a workflow activity exhausts its configured retry policy, the workflow engine will still retry the activity according to the workflow retry policy. This can result in the activity being retried more times than expected. diff --git a/daprdocs/content/en/developing-applications/integrations/kubernetes-operator.md b/daprdocs/content/en/developing-applications/integrations/kubernetes-operator.md index fea913ee3ac..2c08ccdc301 100644 --- a/daprdocs/content/en/developing-applications/integrations/kubernetes-operator.md +++ b/daprdocs/content/en/developing-applications/integrations/kubernetes-operator.md @@ -8,4 +8,4 @@ description: "Use the Dapr Kubernetes Operator to manage the Dapr control plane" You can use the Dapr Kubernetes Operator to manage the Dapr control plane. Use the operator to automate the tasks required to manage the lifecycle of Dapr control plane in Kubernetes mode. -{{< button text="Install and use the Dapr Kubernetes Operator" link="https://github.com/dapr/dapr-kubernetes-operator" >}} +{{< button text="Install and use the Dapr Kubernetes Operator" link="https://github.com/dapr/kubernetes-operator" >}} diff --git a/daprdocs/content/en/developing-applications/sdks/_index.md b/daprdocs/content/en/developing-applications/sdks/_index.md index 909055fb084..4f56c0513bd 100644 --- a/daprdocs/content/en/developing-applications/sdks/_index.md +++ b/daprdocs/content/en/developing-applications/sdks/_index.md @@ -27,7 +27,7 @@ Select your [preferred language below]({{< ref "#sdk-languages" >}}) to learn mo | [Java]({{< ref java >}}) | Stable | ✔ | Spring Boot
Quarkus| ✔ | ✔ | | [Go]({{< ref go >}}) | Stable | ✔ | ✔ | ✔ | ✔ | | [PHP]({{< ref php >}}) | Stable | ✔ | ✔ | ✔ | | -| [Javascript]({{< ref js >}}) | Stable| ✔ | | ✔ | ✔ | +| [JavaScript]({{< ref js >}}) | Stable| ✔ | | ✔ | ✔ | | [C++](https://github.com/dapr/cpp-sdk) | In development | ✔ | | | | [Rust]({{< ref rust >}}) | In development | ✔ | | ✔ | | diff --git a/daprdocs/content/en/getting-started/quickstarts/pubsub-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/pubsub-quickstart.md index 372c106a98d..82d5884424a 100644 --- a/daprdocs/content/en/getting-started/quickstarts/pubsub-quickstart.md +++ b/daprdocs/content/en/getting-started/quickstarts/pubsub-quickstart.md @@ -32,7 +32,7 @@ Select your preferred language-specific Dapr SDK before proceeding with the Quic For this example, you will need: - [Dapr CLI and initialized environment](https://docs.dapr.io/getting-started). -- [Python 3.7+ installed](https://www.python.org/downloads/). +- [Python 3.8+ installed](https://www.python.org/downloads/). - [Docker Desktop](https://www.docker.com/products/docker-desktop) diff --git a/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-serviceinvo-quickstart.md b/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-serviceinvo-quickstart.md index 1dc04aaa4a5..92f92610738 100644 --- a/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-serviceinvo-quickstart.md +++ b/daprdocs/content/en/getting-started/quickstarts/resiliency/resiliency-serviceinvo-quickstart.md @@ -55,7 +55,7 @@ pip3 install -r requirements.txt Run the `order-processor` service alongside a Dapr sidecar. ```bash -dapr run --app-port 8001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- python3 app.py +dapr run --app-port 8001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- python3 app.py ``` ### Step 3: Run the `checkout` service application @@ -75,7 +75,7 @@ pip3 install -r requirements.txt Run the `checkout` service alongside a Dapr sidecar. ```bash -dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- python3 app.py +dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- python3 app.py ``` The Dapr sidecar then loads the resiliency spec located in the resources directory: @@ -262,7 +262,7 @@ npm install Run the `order-processor` service alongside a Dapr sidecar. ```bash -dapr run --app-port 5001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- npm start +dapr run --app-port 5001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- npm start ``` ### Step 3: Run the `checkout` service application @@ -283,7 +283,7 @@ npm install Run the `checkout` service alongside a Dapr sidecar. ```bash -dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- npm start +dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- npm start ``` The Dapr sidecar then loads the resiliency spec located in the resources directory: @@ -426,7 +426,7 @@ Once you restart the `order-processor` service, the application will recover sea In the `order-processor` service terminal, restart the application: ```bash -dapr run --app-port 5001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- npm start +dapr run --app-port 5001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- npm start ``` `checkout` service output: @@ -494,7 +494,7 @@ dotnet build Run the `order-processor` service alongside a Dapr sidecar. ```bash -dapr run --app-port 7001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- dotnet run +dapr run --app-port 7001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- dotnet run ``` ### Step 3: Run the `checkout` service application @@ -516,7 +516,7 @@ dotnet build Run the `checkout` service alongside a Dapr sidecar. ```bash -dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- dotnet run +dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- dotnet run ``` The Dapr sidecar then loads the resiliency spec located in the resources directory: @@ -727,7 +727,7 @@ mvn clean install Run the `order-processor` service alongside a Dapr sidecar. ```bash -dapr run --app-id order-processor --resources-path ../../../resources/ --app-port 9001 --app-protocol http --dapr-http-port 3501 -- java -jar target/OrderProcessingService-0.0.1-SNAPSHOT.jar +dapr run --app-id order-processor --resources-path ../../../resources/ --app-port 9001 --app-protocol http --dapr-http-port 3501 -- java -jar target/OrderProcessingService-0.0.1-SNAPSHOT.jar ``` ### Step 3: Run the `checkout` service application @@ -748,7 +748,7 @@ mvn clean install Run the `checkout` service alongside a Dapr sidecar. ```bash -dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- java -jar target/CheckoutService-0.0.1-SNAPSHOT.jar +dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- java -jar target/CheckoutService-0.0.1-SNAPSHOT.jar ``` The Dapr sidecar then loads the resiliency spec located in the resources directory: @@ -891,7 +891,7 @@ Once you restart the `order-processor` service, the application will recover sea In the `order-processor` service terminal, restart the application: ```bash -dapr run --app-id order-processor --resources-path ../../../resources/ --app-port 9001 --app-protocol http --dapr-http-port 3501 -- java -jar target/OrderProcessingService-0.0.1-SNAPSHOT.jar +dapr run --app-id order-processor --resources-path ../../../resources/ --app-port 9001 --app-protocol http --dapr-http-port 3501 -- java -jar target/OrderProcessingService-0.0.1-SNAPSHOT.jar ``` `checkout` service output: @@ -957,7 +957,7 @@ go build . Run the `order-processor` service alongside a Dapr sidecar. ```bash -dapr run --app-port 6001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- go run . +dapr run --app-port 6001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- go run . ``` ### Step 3: Run the `checkout` service application @@ -978,7 +978,7 @@ go build . Run the `checkout` service alongside a Dapr sidecar. ```bash -dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- go run . +dapr run --app-id checkout --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3500 -- go run . ``` The Dapr sidecar then loads the resiliency spec located in the resources directory: @@ -1121,7 +1121,7 @@ Once you restart the `order-processor` service, the application will recover sea In the `order-processor` service terminal, restart the application: ```bash -dapr run --app-port 6001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- go run . +dapr run --app-port 6001 --app-id order-processor --resources-path ../../../resources/ --app-protocol http --dapr-http-port 3501 -- go run . ``` `checkout` service output: diff --git a/daprdocs/content/en/operations/configuration/configuration-overview.md b/daprdocs/content/en/operations/configuration/configuration-overview.md index 097af8eace1..5b6a4d73df0 100644 --- a/daprdocs/content/en/operations/configuration/configuration-overview.md +++ b/daprdocs/content/en/operations/configuration/configuration-overview.md @@ -110,17 +110,30 @@ metrics: rules: [] http: increasedCardinality: true + pathMatching: + - /items + - /orders/{orderID} + - /orders/{orderID}/items/{itemID} + - /payments/{paymentID} + - /payments/{paymentID}/status + - /payments/{paymentID}/refund + - /payments/{paymentID}/details + excludeVerbs: false ``` +In the examples above, the path filter `/orders/{orderID}/items/{itemID}` would return a single metric count matching all the `orderIDs` and all the `itemIDs`, rather than multiple metrics for each `itemID`. For more information, see [HTTP metrics path matching]({{< ref "metrics-overview.md#http-metrics-path-matching" >}}). + The following table lists the properties for metrics: | Property | Type | Description | |--------------|--------|-------------| | `enabled` | boolean | When set to true, the default, enables metrics collection and the metrics endpoint. | | `rules` | array | Named rule to filter metrics. Each rule contains a set of `labels` to filter on and a `regex` expression to apply to the metrics path. | -| `http.increasedCardinality` | boolean | When set to true, in the Dapr HTTP server each request path causes the creation of a new "bucket" of metrics. This can cause issues, including excessive memory consumption, when there many different requested endpoints (such as when interacting with RESTful APIs).
In Dapr 1.13 the default value is `true` (to preserve the behavior of Dapr <= 1.12), but will change to `false` in Dapr 1.14. | +| `http.increasedCardinality` | boolean | When set to `true` (default), in the Dapr HTTP server, each request path causes the creation of a new "bucket" of metrics. This can cause issues, including excessive memory consumption when there many different requested endpoints (such as when interacting with RESTful APIs).
To mitigate high memory usage and egress costs associated with [high cardinality metrics]({{< ref "metrics-overview.md#high-cardinality-metrics" >}}) with the HTTP server, you should set the `metrics.http.increasedCardinality` property to `false`.| +| `http.pathMatching` | array | Paths used for path matching, allowing users to define matching paths in order to manage cardinality. | +| `http.excludeVerbs` | boolean | When set to `true` (default is `false`), the Dapr HTTP server ignores each request HTTP verb when building the method metric label. | -To mitigate high memory usage and egress costs associated with [high cardinality metrics]({{< ref "metrics-overview.md#high-cardinality-metrics" >}}) with the HTTP server, you should set the `metrics.http.increasedCardinality` property to `false`. +To further help managing cardinality, path matching allows specified paths matched according to defined patterns, reducing the number of unique metrics paths and thus controlling metric cardinality. This feature is particularly useful for applications with dynamic URLs, ensuring that metrics remain meaningful and manageable without excessive memory consumption. Using rules, you can set regular expressions for every metric exposed by the Dapr sidecar. For example: diff --git a/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-dapr-shared.md b/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-dapr-shared.md new file mode 100644 index 00000000000..4bef59fe6e1 --- /dev/null +++ b/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-dapr-shared.md @@ -0,0 +1,87 @@ +--- +type: docs +title: "Deploy Dapr per-node or per-cluster with Dapr Shared" +linkTitle: "Dapr Shared" +weight: 50000 +description: "Learn more about using Dapr Shared as an alternative deployment to sidecars" + +--- + +Dapr automatically injects a sidecar to enable the Dapr APIs for your applications for the best availability and reliability. + +Dapr Shared enables two alternative deployment strategies to create Dapr applications using a Kubernetes `Daemonset` for a per-node deployment or a `Deployment` for a per-cluster deployment. + +- **`DaemonSet`:** When running Dapr Shared as a Kubernetes `DaemonSet` resource, the daprd container runs on each Kubernetes node in the cluster. This can reduce network hops between the applications and Dapr. +- **`Deployment`:** When running Dapr Shared as a Kubernetes `Deployment`, the Kubernetes scheduler decides on which single node in the cluster the daprd container instance runs. + +{{% alert title="Dapr Shared deployments" color="primary" %}} +For each Dapr application you deploy, you need to deploy the Dapr Shared Helm chart using different `shared.appId`s. +{{% /alert %}} + + + +## Why Dapr Shared? + +By default, when Dapr is installed into a Kubernetes cluster, the Dapr control plane injects Dapr as a sidecar to applications annotated with Dapr annotations ( `dapr.io/enabled: "true"`). Sidecars offer many advantages, including improved resiliency, since there is an instance per application and all communication between the application and the sidecar happens without involving the network. + + + + +While sidecars are Dapr's default deployment, some use cases require other approaches. Let's say you want to decouple the lifecycle of your workloads from the Dapr APIs. A typical example of this is functions, or function-as-a-service runtimes, which might automatically downscale your idle workloads to free up resources. For such cases, keeping the Dapr APIs and all the Dapr async functionalities (such as subscriptions) separate might be required. + +Dapr Shared was created for these scenarios, extending the Dapr sidecar model with two new deployment approaches: `DaemonSet` (per-node) and `Deployment` (per-cluster). + +{{% alert title="Important" color="primary" %}} +No matter which deployment approach you choose, it is important to understand that in most use cases, you have one instance of Dapr Shared (Helm release) per service (app-id). This means that if you have an application composed of three microservices, each service is recommended to have its own Dapr Shared instance. You can see this in action by trying the [Hello Kubernetes with Dapr Shared tutorial](https://github.com/dapr/dapr-shared/blob/main/docs/tutorial/README.md). +{{% /alert %}} + + +### `DeamonSet`(Per-node) + +With Kubernetes `DaemonSet`, you can define applications that need to be deployed once per node in the cluster. This enables applications that are running on the same node to communicate with local Dapr APIs, no matter where the Kubernetes `Scheduler` schedules your workload. + + + +{{% alert title="Note" color="primary" %}} +Since `DaemonSet` installs one instance per node, it consumes more resources in your cluster, compared to `Deployment` for a per cluster deployment, with the advantage of improved resiliency. +{{% /alert %}} + + +### `Deployment` (Per-cluster) + +Kubernetes `Deployments` are installed once per cluster. Based on available resources, the Kubernetes `Scheduler` decides on which node the workload is scheduled. For Dapr Shared, this means that your workload and the Dapr instance might be located on separate nodes, which can introduce considerable network latency with the trade-off of reduce resource usage. + + + +## Getting Started with Dapr Shared + +{{% alert title="Prerequisites" color="primary" %}} +Before installing Dapr Shared, make ensure you have [Dapr installed in your cluster]({{< ref "kubernetes-deploy.md" >}}). +{{% /alert %}} + +If you want to get started with Dapr Shared, you can create a new Dapr Shared instance by installing the official Helm Chart: + +``` +helm install my-shared-instance oci://registry-1.docker.io/daprio/dapr-shared-chart --set shared.appId= --set shared.remoteURL= --set shared.remotePort= --set shared.strategy=deployment +``` + +Your Dapr-enabled applications can now make use of the Dapr Shared instance by pointing the Dapr SDKs to or sending requests to the `my-shared-instance-dapr` Kubernetes service exposed by the Dapr Shared instance. + +> The `my-shared-instance` above is the Helm Chart release name. + +If you are using the Dapr SDKs, you can set the following environment variables for your application to connect to the Dapr Shared instance (in this case, running on the `default` namespace): + +``` + env: + - name: DAPR_HTTP_ENDPOINT + value: http://my-shared-instance-dapr.default.svc.cluster.local:3500 + - name: DAPR_GRPC_ENDPOINT + value: http://my-shared-instance-dapr.default.svc.cluster.local:50001 +``` + +If you are not using the SDKs, you can send HTTP or gRPC requests to those endpoints. + +## Next steps + +- Try the [Hello Kubernetes tutorial with Dapr Shared](https://github.com/dapr/dapr-shared/blob/main/docs/tutorial/README.md). +- Read more in the [Dapr Shared repo](https://github.com/dapr/dapr-shared/blob/main/README.md) diff --git a/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-hybrid-clusters.md b/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-hybrid-clusters.md index b76d682fa0f..c2385c9f990 100644 --- a/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-hybrid-clusters.md +++ b/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-hybrid-clusters.md @@ -2,7 +2,7 @@ type: docs title: "Deploy to hybrid Linux/Windows Kubernetes clusters" linkTitle: "Hybrid clusters" -weight: 60000 +weight: 70000 description: "How to run Dapr apps on Kubernetes clusters with Windows nodes" --- diff --git a/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-job.md b/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-job.md index e4aebbbbb15..11bae378069 100644 --- a/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-job.md +++ b/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-job.md @@ -2,7 +2,7 @@ type: docs title: "Running Dapr with a Kubernetes Job" linkTitle: "Kubernetes Jobs" -weight: 70000 +weight: 80000 description: "Use Dapr API in a Kubernetes Job context" --- diff --git a/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-volume-mounts.md b/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-volume-mounts.md index 00ee915dda2..aa93ca17f52 100644 --- a/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-volume-mounts.md +++ b/daprdocs/content/en/operations/hosting/kubernetes/kubernetes-volume-mounts.md @@ -2,7 +2,7 @@ type: docs title: "How-to: Mount Pod volumes to the Dapr sidecar" linkTitle: "How-to: Mount Pod volumes" -weight: 80000 +weight: 90000 description: "Configure the Dapr sidecar to mount Pod Volumes" --- diff --git a/daprdocs/content/en/operations/observability/metrics/metrics-overview.md b/daprdocs/content/en/operations/observability/metrics/metrics-overview.md index e26453d09f6..da2ec6fc333 100644 --- a/daprdocs/content/en/operations/observability/metrics/metrics-overview.md +++ b/daprdocs/content/en/operations/observability/metrics/metrics-overview.md @@ -70,15 +70,135 @@ spec: enabled: false ``` -## High cardinality metrics +## Optimizing HTTP metrics reporting with path matching -When invoking Dapr using HTTP, the legacy behavior (and current default as of Dapr 1.13) is to create a separate "bucket" for each requested method. When working with RESTful APIs, this can cause very high cardinality, with potential negative impact on memory usage and CPU. +When invoking Dapr using HTTP, metrics are created for each requested method by default. This can result in a high number of metrics, known as high cardinality, which can impact memory usage and CPU. -Dapr 1.13 introduces a new option for the Dapr Configuration resource `spec.metrics.http.increasedCardinality`: when set to `false`, it reports metrics for the HTTP server for each "abstract" method (for example, requesting from a state store) instead of creating a "bucket" for each concrete request path. +Path matching allows you to manage and control the cardinality of HTTP metrics in Dapr. This is an aggregation of metrics, so rather than having a metric for each event, you can reduce the number of metrics events and report an overall number. For details on how to set the cardinality in configuration see ({{< ref "configuration-overview.md#metrics" >}}) + +This configuration is opt-in and is enabled via the Dapr configuration `spec.metrics.http.pathMatching`. When defined, it enables path matching, which standardizes specified paths for both metrics paths. This reduces the number of unique metrics paths, making metrics more manageable and reducing resource consumption in a controlled way. + +When `spec.metrics.http.pathMatching` is combined with the `increasedCardinality` flag set to `false`, non-matched paths are transformed into a catch-all bucket to control and limit cardinality, preventing unbounded path growth. Conversely, when `increasedCardinality` is `true` (the default), non-matched paths are passed through as they normally would be, allowing for potentially higher cardinality but preserving the original path data. + +### Examples of Path Matching in HTTP Metrics + +The following examples demonstrate how to use the Path Matching API in Dapr for managing HTTP metrics. On each example, the metrics are collected from 5 HTTP requests to the `/orders` endpoint with different order IDs. By adjusting cardinality and utilizing path matching, you can fine-tune metric granularity to balance detail and resource efficiency. + +These examples illustrate the cardinality of the metrics, highlighting that high cardinality configurations result in many entries, which correspond to higher memory usage for handling metrics. For simplicity, the following example focuses on a single metric: `dapr_http_server_request_count`. + +#### Low cardinality with path matching (Recommendation) + +Configuration: +```yaml +http: + increasedCardinality: false + pathMatching: + - /orders/{orderID} +``` + +Metrics generated: +``` +# matched paths +dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders/{orderID}",status="200"} 5 +# unmatched paths +dapr_http_server_request_count{app_id="order-service",method="GET",path="",status="200"} 1 +``` + +With low cardinality and path matching configured, you get the best of both worlds by grouping the metrics for the important endpoints without compromising the cardinality. This approach helps avoid high memory usage and potential security issues. + +#### Low cardinality without path matching + +Configuration: + +```yaml +http: + increasedCardinality: false +``` +Metrics generated: +``` +dapr_http_server_request_count{app_id="order-service",method="GET", path="",status="200"} 5 +``` + +In low cardinality mode, the path, which is the main source of unbounded cardinality, is dropped. This results in metrics that primarily indicate the number of requests made to the service for a given HTTP method, but without any information about the paths invoked. + + +#### High cardinality with path matching + +Configuration: +```yaml +http: + increasedCardinality: true + pathMatching: + - /orders/{orderID} +``` + +Metrics generated: +``` +dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders/{orderID}",status="200"} 5 +``` + +This example results from the same HTTP requests as the example above, but with path matching configured for the path `/orders/{orderID}`. By using path matching, you achieve reduced cardinality by grouping the metrics based on the matched path. + +#### High Cardinality without path matching + +Configuration: +```yaml +http: + increasedCardinality: true +``` + +Metrics generated: +``` +dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders/1",status="200"} 1 +dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders/2",status="200"} 1 +dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders/3",status="200"} 1 +dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders/4",status="200"} 1 +dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders/5",status="200"} 1 +``` + +For each request, a new metric is created with the request path. This process continues for every request made to a new order ID, resulting in unbounded cardinality since the IDs are ever-growing. + + +### HTTP metrics exclude verbs + +The `excludeVerbs` option allows you to exclude specific HTTP verbs from being reported in the metrics. This can be useful in high-performance applications where memory savings are critical. + +### Examples of excluding HTTP verbs in metrics + +The following examples demonstrate how to exclude HTTP verbs in Dapr for managing HTTP metrics. + +#### Default - Include HTTP verbs + +Configuration: +```yaml +http: + excludeVerbs: false +``` + +Metrics generated: +``` +dapr_http_server_request_count{app_id="order-service",method="GET",path="/orders",status="200"} 1 +dapr_http_server_request_count{app_id="order-service",method="POST",path="/orders",status="200"} 1 +``` + +In this example, the HTTP method is included in the metrics, resulting in a separate metric for each request to the `/orders` endpoint. + +#### Exclude HTTP verbs + +Configuration: +```yaml +http: + excludeVerbs: true +``` + +Metrics generated: +``` +dapr_http_server_request_count{app_id="order-service",method="",path="/orders",status="200"} 2 +``` + +In this example, the HTTP method is excluded from the metrics, resulting in a single metric for all requests to the `/orders` endpoint. -The default value of `spec.metrics.http.increasedCardinality` is `true` in Dapr 1.13, to maintain the same behavior as Dapr 1.12 and older. However, the value will change to `false` (low-cardinality metrics by default) in Dapr 1.14. -Setting `spec.metrics.http.increasedCardinality` to `false` is **recommended** to all Dapr users, to reduce resource consumption. The pre-1.13 behavior, which is used when the option is `true`, is considered legacy and is only maintained for users who have special requirements around backwards-compatibility. ## Transform metrics with regular expressions diff --git a/daprdocs/content/en/reference/api/actors_api.md b/daprdocs/content/en/reference/api/actors_api.md index 79710612b98..b5dd2c62659 100644 --- a/daprdocs/content/en/reference/api/actors_api.md +++ b/daprdocs/content/en/reference/api/actors_api.md @@ -114,7 +114,7 @@ Parameter | Description #### Examples -> Note, the following example uses the `ttlInSeconds` field, which requires the [`ActorStateTTL` feature enabled]]({{< ref "support-preview-features.md" >}}). +> Note, the following example uses the `ttlInSeconds` field, which requires the [`ActorStateTTL` feature enabled]({{< ref "support-preview-features.md" >}}). ```shell curl -X POST http://localhost:3500/v1.0/actors/stormtrooper/50/state \ @@ -202,6 +202,8 @@ A JSON object with the following fields: |-------|--------------| | `dueTime` | Specifies the time after which the reminder is invoked. Its format should be [time.ParseDuration](https://pkg.go.dev/time#ParseDuration) | `period` | Specifies the period between different invocations. Its format should be [time.ParseDuration](https://pkg.go.dev/time#ParseDuration) or ISO 8601 duration format with optional recurrence. +| `ttl` | Sets time at or interval after which the timer or reminder will be expired and deleted. Its format should be [time.ParseDuration format](https://pkg.go.dev/time#ParseDuration), RFC3339 date format, or ISO 8601 duration format. +| `data` | A string value and can be any related content. Content is returned when the reminder expires. For example this may be useful for returning a URL or anything related to the content. `period` field supports `time.Duration` format and ISO 8601 format with some limitations. For `period`, only duration format of ISO 8601 duration `Rn/PnYnMnWnDTnHnMnS` is supported. `Rn/` specifies that the reminder will be invoked `n` number of times. @@ -210,7 +212,11 @@ A JSON object with the following fields: If `Rn/` is not specified, the reminder will run an infinite number of times until deleted. -The following specifies a `dueTime` of 3 seconds and a period of 7 seconds. +If only `ttl` and `dueTime` are set, the reminder will be accepted. However, only the `dueTime` takes effect. For example, the reminder triggers at `dueTime`, and `ttl` is ignored. + +If `ttl`, `dueTime`, and `period` are set, the reminder first fires at `dueTime`, then repeatedly fires and expires according to `period` and `ttl`. + +The following example specifies a `dueTime` of 3 seconds and a period of 7 seconds. ```json { @@ -237,6 +243,25 @@ To configure the reminder to fire only once, the period should be set to empty s } ``` +When you specify the repetition number in both `period` and `ttl`, the timer/reminder is stopped when either condition is met. The following example has a timer with a `period` of 3 seconds (in ISO 8601 duration format) and a `ttl` of 20 seconds. This timer fires immediately after registration, then every 3 seconds after that for the duration of 20 seconds, after which it never fires again since the `ttl` was met + +```json +{ + "period":"PT3S", + "ttl":"20s" +} +``` + +Need description for data. + +```json +{ + "data": "someData", + "dueTime": "1m", + "period": "20s" +} +``` + #### HTTP Response Codes Code | Description diff --git a/daprdocs/content/en/reference/resource-specs/configuration-schema.md b/daprdocs/content/en/reference/resource-specs/configuration-schema.md index 746d4b5c390..3507975de98 100644 --- a/daprdocs/content/en/reference/resource-specs/configuration-schema.md +++ b/daprdocs/content/en/reference/resource-specs/configuration-schema.md @@ -38,6 +38,10 @@ spec: regex: {} http: increasedCardinality: + pathMatching: + - + - + excludeVerbs: httpPipeline: # for incoming http calls handlers: - name: diff --git a/daprdocs/layouts/shortcodes/dapr-latest-version.html b/daprdocs/layouts/shortcodes/dapr-latest-version.html index 6aa8e1f8137..68a8266ae7a 100644 --- a/daprdocs/layouts/shortcodes/dapr-latest-version.html +++ b/daprdocs/layouts/shortcodes/dapr-latest-version.html @@ -1 +1 @@ -{{- if .Get "short" }}1.13{{ else if .Get "long" }}1.13.4{{ else if .Get "cli" }}1.13.4{{ else }}1.13.4{{ end -}} \ No newline at end of file +{{- if .Get "short" }}1.13{{ else if .Get "long" }}1.13.4{{ else if .Get "cli" }}1.13.0{{ else }}1.13.4{{ end -}} diff --git a/daprdocs/package-lock.json b/daprdocs/package-lock.json index adc813bba76..6bcdae97208 100644 --- a/daprdocs/package-lock.json +++ b/daprdocs/package-lock.json @@ -178,12 +178,12 @@ } }, "node_modules/braces": { - "version": "3.0.2", - "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.2.tgz", - "integrity": "sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==", + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz", + "integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==", "dev": true, "dependencies": { - "fill-range": "^7.0.1" + "fill-range": "^7.1.1" }, "engines": { "node": ">=8" @@ -400,9 +400,9 @@ } }, "node_modules/fill-range": { - "version": "7.0.1", - "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.0.1.tgz", - "integrity": "sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==", + "version": "7.1.1", + "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz", + "integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==", "dev": true, "dependencies": { "to-regex-range": "^5.0.1" diff --git a/daprdocs/static/images/dapr-shared/daemonset.png b/daprdocs/static/images/dapr-shared/daemonset.png new file mode 100644 index 00000000000..25ee4047331 Binary files /dev/null and b/daprdocs/static/images/dapr-shared/daemonset.png differ diff --git a/daprdocs/static/images/dapr-shared/deployment.png b/daprdocs/static/images/dapr-shared/deployment.png new file mode 100644 index 00000000000..0cf7c90df42 Binary files /dev/null and b/daprdocs/static/images/dapr-shared/deployment.png differ diff --git a/daprdocs/static/images/dapr-shared/sidecar.png b/daprdocs/static/images/dapr-shared/sidecar.png new file mode 100644 index 00000000000..77eba93c7ec Binary files /dev/null and b/daprdocs/static/images/dapr-shared/sidecar.png differ diff --git a/daprdocs/static/images/secrets-overview-azure-aks-keyvault.png b/daprdocs/static/images/secrets-overview-azure-aks-keyvault.png index 6b1f4b505e0..b5e6482eb25 100644 Binary files a/daprdocs/static/images/secrets-overview-azure-aks-keyvault.png and b/daprdocs/static/images/secrets-overview-azure-aks-keyvault.png differ diff --git a/daprdocs/static/images/secrets-overview-cloud-stores.png b/daprdocs/static/images/secrets-overview-cloud-stores.png index 3e8568d1182..a42a55e9a34 100644 Binary files a/daprdocs/static/images/secrets-overview-cloud-stores.png and b/daprdocs/static/images/secrets-overview-cloud-stores.png differ diff --git a/daprdocs/static/images/secrets-overview-kubernetes-store.png b/daprdocs/static/images/secrets-overview-kubernetes-store.png index 488b8401690..f2368708532 100644 Binary files a/daprdocs/static/images/secrets-overview-kubernetes-store.png and b/daprdocs/static/images/secrets-overview-kubernetes-store.png differ diff --git a/daprdocs/static/presentations/dapr-slidedeck.pptx.zip b/daprdocs/static/presentations/dapr-slidedeck.pptx.zip index 5869ced2e5f..1ccec7c23c0 100644 Binary files a/daprdocs/static/presentations/dapr-slidedeck.pptx.zip and b/daprdocs/static/presentations/dapr-slidedeck.pptx.zip differ