diff --git a/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-non-dapr-endpoints.md b/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-non-dapr-endpoints.md index ec48330e35c..28c3cb8f1ec 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-non-dapr-endpoints.md +++ b/daprdocs/content/en/developing-applications/building-blocks/service-invocation/howto-invoke-non-dapr-endpoints.md @@ -70,7 +70,7 @@ There are two ways to invoke a non-Dapr endpoint when communicating either to Da ``` ### Using appId when calling Dapr enabled applications -AppIDs are always used to call Dapr applications with the `appID` and `my-method``. Read the [How-To: Invoke services using HTTP]({{< ref howto-invoke-discover-services.md >}}) guide for more information. For example: +AppIDs are always used to call Dapr applications with the `appID` and `my-method`. Read the [How-To: Invoke services using HTTP]({{< ref howto-invoke-discover-services.md >}}) guide for more information. For example: ```sh localhost:3500/v1.0/invoke//method/ diff --git a/daprdocs/content/en/operations/components/component-secrets.md b/daprdocs/content/en/operations/components/component-secrets.md index b7e1f0a51f7..d894865251b 100644 --- a/daprdocs/content/en/operations/components/component-secrets.md +++ b/daprdocs/content/en/operations/components/component-secrets.md @@ -75,15 +75,14 @@ spec: type: bindings.azure.servicebusqueues version: v1 metadata: - -name: connectionString - secretKeyRef: + - name: connectionString + secretKeyRef: name: asbNsConnString key: asbNsConnString - -name: queueName - value: servicec-inputq + - name: queueName + value: servicec-inputq auth: secretStore: - ``` The above "Secret is a string" case yaml tells Dapr to extract a connection string named `asbNsConnstring` from the defined `secretStore` and assign the value to the `connectionString` field in the component since there is no key embedded in the "secret" from the `secretStore` because it is a plain string. This requires the secret `name` and secret `key` to be identical. @@ -95,7 +94,7 @@ The following example shows you how to create a Kubernetes secret to hold the co 1. First, create the Kubernetes secret: ```bash - kubectl create secret generic eventhubs-secret --from-literal=connectionString=********* + kubectl create secret generic eventhubs-secret --from-literal=connectionString=********* ``` 2. Next, reference the secret in your binding: diff --git a/daprdocs/content/en/operations/components/pluggable-components-registration.md b/daprdocs/content/en/operations/components/pluggable-components-registration.md index 10f6a057715..7aecca49458 100644 --- a/daprdocs/content/en/operations/components/pluggable-components-registration.md +++ b/daprdocs/content/en/operations/components/pluggable-components-registration.md @@ -52,7 +52,7 @@ Since you are running Dapr in the same host as the component, verify that this f ### Component discovery and multiplexing -A pluggable component accessible through a [Unix Domain Socket][UDS] (UDS) can host multiple distinct component APIs . During the components' initial discovery process, Dapr uses reflection to enumerate all the component APIs behind a UDS. The `my-component` pluggable component in the example above can contain both state store (`state`) and a pub/sub (`pubsub`) component APIs. +A pluggable component accessible through a [Unix Domain Socket][UDS] (UDS) can host multiple distinct component APIs. During the components' initial discovery process, Dapr uses reflection to enumerate all the component APIs behind a UDS. The `my-component` pluggable component in the example above can contain both state store (`state`) and a pub/sub (`pubsub`) component APIs. Typically, a pluggable component implements a single component API for packaging and deployment. However, at the expense of increasing its dependencies and broadening its security attack surface, a pluggable component can have multiple component APIs implemented. This could be done to ease the deployment and monitoring burden. Best practice for isolation, fault tolerance, and security is a single component API implementation for each pluggable component. diff --git a/daprdocs/content/en/operations/observability/tracing/setup-tracing.md b/daprdocs/content/en/operations/observability/tracing/setup-tracing.md index 4fd3f40bca6..9a04f6bc90d 100644 --- a/daprdocs/content/en/operations/observability/tracing/setup-tracing.md +++ b/daprdocs/content/en/operations/observability/tracing/setup-tracing.md @@ -20,7 +20,7 @@ spec: tracing: samplingRate: "1" otel: - endpointAddress: "https://..." + endpointAddress: "myendpoint.cluster.local:4317" zipkin: endpointAddress: "https://..." @@ -32,10 +32,10 @@ The following table lists the properties for tracing: |--------------|--------|-------------| | `samplingRate` | string | Set sampling rate for tracing to be enabled or disabled. | `stdout` | bool | True write more verbose information to the traces -| `otel.endpointAddress` | string | Set the Open Telemetry (OTEL) server address. +| `otel.endpointAddress` | string | Set the Open Telemetry (OTEL) target hostname and optionally port. If this is used, you do not need to specify the 'zipkin' section. | `otel.isSecure` | bool | Is the connection to the endpoint address encrypted. | `otel.protocol` | string | Set to `http` or `grpc` protocol. -| `zipkin.endpointAddress` | string | Set the Zipkin server address. If this is used, you do not need to specify the `otel` section. +| `zipkin.endpointAddress` | string | Set the Zipkin server URL. If this is used, you do not need to specify the `otel` section. To enable tracing, use a configuration file (in self hosted mode) or a Kubernetes configuration object (in Kubernetes mode). For example, the following configuration object changes the sample rate to 1 (every span is sampled), and sends trace using OTEL protocol to the OTEL server at localhost:4317 @@ -66,7 +66,7 @@ turns on tracing for the sidecar. | Environment Variable | Description | |----------------------|-------------| -| `OTEL_EXPORTER_OTLP_ENDPOINT` | Sets the Open Telemetry (OTEL) server address, turns on tracing | +| `OTEL_EXPORTER_OTLP_ENDPOINT` | Sets the Open Telemetry (OTEL) server hostname and optionally port, turns on tracing | | `OTEL_EXPORTER_OTLP_INSECURE` | Sets the connection to the endpoint as unencrypted (true/false) | | `OTEL_EXPORTER_OTLP_PROTOCOL` | Transport protocol (`grpc`, `http/protobuf`, `http/json`) | diff --git a/daprdocs/content/en/operations/support/support-release-policy.md b/daprdocs/content/en/operations/support/support-release-policy.md index 51e11749b8a..46543b49f52 100644 --- a/daprdocs/content/en/operations/support/support-release-policy.md +++ b/daprdocs/content/en/operations/support/support-release-policy.md @@ -45,6 +45,7 @@ The table below shows the versions of Dapr releases that have been tested togeth | Release date | Runtime | CLI | SDKs | Dashboard | Status | Release notes | |--------------------|:--------:|:--------|---------|---------|---------|------------| +| May 21st 2024 | 1.13.3
| 1.13.0 | Java 1.11.0
Go 1.10.0
PHP 1.2.0
Python 1.13.0
.NET 1.13.0
JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.3 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.3) | | April 3rd 2024 | 1.13.2
| 1.13.0 | Java 1.11.0
Go 1.10.0
PHP 1.2.0
Python 1.13.0
.NET 1.13.0
JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.2 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.2) | | March 26th 2024 | 1.13.1
| 1.13.0 | Java 1.11.0
Go 1.10.0
PHP 1.2.0
Python 1.13.0
.NET 1.13.0
JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.1 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.1) | | March 6th 2024 | 1.13.0
| 1.13.0 | Java 1.11.0
Go 1.10.0
PHP 1.2.0
Python 1.13.0
.NET 1.13.0
JS 3.3.0 | 0.14.0 | Supported (current) | [v1.13.0 release notes](https://github.com/dapr/dapr/releases/tag/v1.13.0) | @@ -136,6 +137,7 @@ General guidance on upgrading can be found for [self hosted mode]({{< ref self-h | 1.11.0 | N/A | 1.11.4 | | 1.12.0 | N/A | 1.12.4 | | 1.13.0 | N/A | 1.13.2 | +| 1.13.0 | N/A | 1.13.3 | ## Upgrade on Hosting platforms diff --git a/daprdocs/content/en/reference/cli/dapr-init.md b/daprdocs/content/en/reference/cli/dapr-init.md index b40af670116..9e517cfa95c 100644 --- a/daprdocs/content/en/reference/cli/dapr-init.md +++ b/daprdocs/content/en/reference/cli/dapr-init.md @@ -74,7 +74,7 @@ dapr init -s You can also specify a specific runtime version. Be default, the latest version is used. ```bash -dapr init --runtime-version 1.13.0 +dapr init --runtime-version 1.13.3 ``` **Install with image variant** diff --git a/daprdocs/layouts/shortcodes/dapr-latest-version.html b/daprdocs/layouts/shortcodes/dapr-latest-version.html index 108b35c0726..7920173103f 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.0{{ else if .Get "cli" }}1.13.0{{ else }}1.13.0{{ end -}} \ No newline at end of file +{{- if .Get "short" }}1.13{{ else if .Get "long" }}1.13.3{{ else if .Get "cli" }}1.13.3{{ else }}1.13.3{{ end -}} \ No newline at end of file