mirror of https://github.com/dapr/docs.git
Merge branch 'v1.11' into add-scheduled-message-example
This commit is contained in:
commit
2662d53e6e
|
|
@ -25,13 +25,14 @@ The diagram below is an example of how dead letter topics work. First a message
|
|||
The following YAML shows how to configure a subscription with a dead letter topic named `poisonMessages` for messages consumed from the `orders` topic. This subscription is scoped to an app with a `checkout` ID.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
apiVersion: dapr.io/v2alpha1
|
||||
kind: Subscription
|
||||
metadata:
|
||||
name: order
|
||||
spec:
|
||||
topic: orders
|
||||
route: /checkout
|
||||
routes:
|
||||
default: /checkout
|
||||
pubsubname: pubsub
|
||||
deadLetterTopic: poisonMessages
|
||||
scopes:
|
||||
|
|
@ -86,13 +87,16 @@ spec:
|
|||
Remember to now configure a subscription to handling the dead letter topics. For example you can create another declarative subscription to receive these on the same or a different application. The example below shows the checkout application subscribing to the `poisonMessages` topic with another subscription and sending these to be handled by the `/failedmessages` endpoint.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
apiVersion: dapr.io/v2alpha1
|
||||
kind: Subscription
|
||||
metadata:
|
||||
name: deadlettertopics
|
||||
spec:
|
||||
topic: poisonMessages
|
||||
route: /failedMessages
|
||||
routes:
|
||||
rules:
|
||||
- match:
|
||||
path: /failedMessages
|
||||
pubsubname: pubsub
|
||||
scopes:
|
||||
- checkout
|
||||
|
|
|
|||
|
|
@ -141,13 +141,14 @@ $app->start();
|
|||
Similarly, you can subscribe to raw events declaratively by adding the `rawPayload` metadata entry to your subscription specification.
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
apiVersion: dapr.io/v2alpha1
|
||||
kind: Subscription
|
||||
metadata:
|
||||
name: myevent-subscription
|
||||
spec:
|
||||
topic: deathStarStatus
|
||||
route: /dsstatus
|
||||
routes:
|
||||
default: /dsstatus
|
||||
pubsubname: pubsub
|
||||
metadata:
|
||||
rawPayload: "true"
|
||||
|
|
|
|||
|
|
@ -22,13 +22,14 @@ The examples below demonstrate pub/sub messaging between a `checkout` app and an
|
|||
You can subscribe declaratively to a topic using an external component file. This example uses a YAML component file named `subscription.yaml`:
|
||||
|
||||
```yaml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
apiVersion: dapr.io/v2alpha1
|
||||
kind: Subscription
|
||||
metadata:
|
||||
name: order
|
||||
spec:
|
||||
topic: orders
|
||||
route: /checkout
|
||||
routes:
|
||||
default: /checkout
|
||||
pubsubname: pubsub
|
||||
scopes:
|
||||
- orderprocessing
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ The diagram below is an overview of how Dapr's service invocation works when inv
|
|||
## Using an HTTPEndpoint resource or FQDN URL for non-Dapr endpoints
|
||||
There are two ways to invoke a non-Dapr endpoint when communicating either to Dapr applications or non-Dapr applications. A Dapr application can invoke a non-Dapr endpoint by providing one of the following:
|
||||
|
||||
- A named `HTTPEndpoint` resource, including defining an `HTTPEndpoint` resource type. See the [HTTPEndpoint reference]({{< ref httpendpoints-reference.md >}}) guide for an example.
|
||||
- A named `HTTPEndpoint` resource, including defining an `HTTPEndpoint` resource type. See the [HTTPEndpoint reference]({{< ref httpendpoints-schema.md >}}) guide for an example.
|
||||
|
||||
```sh
|
||||
localhost:3500/v1.0/invoke/<HTTPEndpoint-name>/method/<my-method>
|
||||
|
|
@ -81,7 +81,7 @@ curl http://localhost:3602/v1.0/invoke/orderprocessor/method/checkout
|
|||
|
||||
## Related Links
|
||||
|
||||
- [HTTPEndpoint reference]({{< ref httpendpoints-reference.md >}})
|
||||
- [HTTPEndpoint reference]({{< ref httpendpoints-schema.md >}})
|
||||
- [Service invocation overview]({{< ref service-invocation-overview.md >}})
|
||||
- [Service invocation API specification]({{< ref service_invocation_api.md >}})
|
||||
|
||||
|
|
|
|||
|
|
@ -16,9 +16,15 @@ When state TTL has native support in the state store component, Dapr forwards th
|
|||
|
||||
When a TTL is not specified, the default behavior of the state store is retained.
|
||||
|
||||
## Persisting state (ignoring an existing TTL)
|
||||
## Explicit persistence bypassing globally defined TTL
|
||||
|
||||
To explicitly persist a state (ignoring any TTLs set for the key), specify a `ttlInSeconds` value of `-1`.
|
||||
Persisting state applies to all state stores that let you specify a default TTL used for all data, either:
|
||||
- Setting a global TTL value via a Dapr component, or
|
||||
- When creating the state store outside of Dapr and setting a global TTL value.
|
||||
|
||||
When no specific TTL is specified, the data expires after that global TTL period of time. This is not facilitated by Dapr.
|
||||
|
||||
In addition, all state stores also support the option to _explicitly_ persist data. This means you can ignore the default database policy (which may have been set outside of Dapr or via a Dapr Component) to indefinitely retain a given database record. You can do this by setting `ttlInSeconds` to the value of `-1`. This value indicates to ignore any TTL value set.
|
||||
|
||||
## Supported components
|
||||
|
||||
|
|
|
|||
|
|
@ -12,12 +12,6 @@ The workflow building block is currently in **alpha**.
|
|||
|
||||
Let's take a look at the Dapr [Workflow building block]({{< ref workflow >}}). In this Quickstart, you'll create a simple console application to demonstrate Dapr's workflow programming model and the workflow management APIs.
|
||||
|
||||
The `order-processor` console app starts and manages the lifecycle of the `OrderProcessingWorkflow` workflow that stores and retrieves data in a state store. The workflow consists of four workflow activities, or tasks:
|
||||
- `NotifyActivity`: Utilizes a logger to print out messages throughout the workflow
|
||||
- `ReserveInventoryActivity`: Checks the state store to ensure that there is enough inventory for the purchase
|
||||
- `ProcessPaymentActivity`: Processes and authorizes the payment
|
||||
- `UpdateInventoryActivity`: Removes the requested items from the state store and updates the store with the new remaining inventory value
|
||||
|
||||
In this guide, you'll:
|
||||
|
||||
- Run the `order-processor` application.
|
||||
|
|
@ -26,13 +20,19 @@ In this guide, you'll:
|
|||
|
||||
<img src="/images/workflow-quickstart-overview.png" width=800 style="padding-bottom:15px;">
|
||||
|
||||
Currently, you can experience the Dapr Workflow using the .NET SDK.
|
||||
|
||||
{{< tabs ".NET" "Python" >}}
|
||||
|
||||
<!-- .NET -->
|
||||
{{% codetab %}}
|
||||
|
||||
The `order-processor` console app starts and manages the lifecycle of an order processing workflow that stores and retrieves data in a state store. The workflow consists of four workflow activities, or tasks:
|
||||
- `NotifyActivity`: Utilizes a logger to print out messages throughout the workflow
|
||||
- `ReserveInventoryActivity`: Checks the state store to ensure that there is enough inventory for the purchase
|
||||
- `ProcessPaymentActivity`: Processes and authorizes the payment
|
||||
- `UpdateInventoryActivity`: Removes the requested items from the state store and updates the store with the new remaining inventory value
|
||||
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
|
@ -259,6 +259,16 @@ The `Activities` directory holds the four workflow activities used by the workfl
|
|||
<!-- Python -->
|
||||
{{% codetab %}}
|
||||
|
||||
The `order-processor` console app starts and manages the `order_processing_workflow`, which simulates purchasing items from a store. The workflow consists of five unique workflow activities, or tasks:
|
||||
|
||||
- `notify_activity`: Utilizes a logger to print out messages throughout the workflow. These messages notify you when:
|
||||
- You have insufficient inventory
|
||||
- Your payment couldn't be processed, etc.
|
||||
- `process_payment_activity`: Processes and authorizes the payment.
|
||||
- `verify_inventory_activity`: Checks the state store to ensure there is enough inventory present for purchase.
|
||||
- `update_inventory_activity`: Removes the requested items from the state store and updates the store with the new remaining inventory value.
|
||||
- `request_approval_activity`: Seeks approval from the manager if payment is greater than 50,000 USD.
|
||||
|
||||
### Step 1: Pre-requisites
|
||||
|
||||
For this example, you will need:
|
||||
|
|
|
|||
|
|
@ -32,8 +32,8 @@ Patch support is for supported versions (current and previous).
|
|||
|
||||
The Dapr's sidecar image is published to both [GitHub Container Registry](https://github.com/dapr/dapr/pkgs/container/daprd) and [Docker Registry](https://hub.docker.com/r/daprio/daprd/tags). The default image contains all components. From version 1.11, Dapr also offers a variation of the sidecar image, containing only stable components.
|
||||
|
||||
* Default sidecar images: `daprio/daprd:<version>` or `ghcr.io/dapr/daprd:<version>` (for example `ghcr.io/dapr/daprd:1.11.0`)
|
||||
* Sidecar images for stable components: `daprio/daprd:<version>-stablecomponents` or `ghcr.io/dapr/daprd:<version>-stablecomponents` (for example `ghcr.io/dapr/daprd:1.11.0-stablecomponents`)
|
||||
* Default sidecar images: `daprio/daprd:<version>` or `ghcr.io/dapr/daprd:<version>` (for example `ghcr.io/dapr/daprd:1.11.1`)
|
||||
* Sidecar images for stable components: `daprio/daprd:<version>-stablecomponents` or `ghcr.io/dapr/daprd:<version>-stablecomponents` (for example `ghcr.io/dapr/daprd:1.11.1-stablecomponents`)
|
||||
|
||||
On Kubernetes, the sidecar image can be overwritten for the application Deployment resource with the `dapr.io/sidecar-image` annotation. See more about [Dapr's arguments and annotations]({{<ref "arguments-annotations-overview.md" >}}). The default 'daprio/daprd:latest' image is used if not specified.
|
||||
|
||||
|
|
@ -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 |
|
||||
|--------------------|:--------:|:--------|---------|---------|---------|
|
||||
| June 22nd 2023 | 1.11.1</br> | 1.11.0 | Java 1.9.0 </br>Go 1.8.0 </br>PHP 1.1.0 </br>Python 1.10.0 </br>.NET 1.11.0 </br>JS 3.1.0 | 0.13.0 | Supported (current) |
|
||||
| June 12th 2023 | 1.11.0</br> | 1.11.0 | Java 1.9.0 </br>Go 1.8.0 </br>PHP 1.1.0 </br>Python 1.10.0 </br>.NET 1.11.0 </br>JS 3.1.0 | 0.13.0 | Supported (current) |
|
||||
| May 15th 2023 | 1.10.7</br> | 1.10.0 | Java 1.8.0 </br>Go 1.7.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 3.0.0 | 0.11.0 | Supported |
|
||||
| May 12th 2023 | 1.10.6</br> | 1.10.0 | Java 1.8.0 </br>Go 1.7.0 </br>PHP 1.1.0 </br>Python 1.9.0 </br>.NET 1.10.0 </br>JS 3.0.0 | 0.11.0 | Supported |
|
||||
|
|
@ -116,8 +117,8 @@ General guidance on upgrading can be found for [self hosted mode]({{< ref self-h
|
|||
| | 1.9.6 | 1.10.7 |
|
||||
| 1.8.0 to 1.8.6 | N/A | 1.9.6 |
|
||||
| 1.9.0 | N/A | 1.9.6 |
|
||||
| 1.10.0 | N/A | 1.10.7 |
|
||||
| 1.11.0 | N/A | 1.11.0 |
|
||||
| 1.10.0 | N/A | 1.10.8 |
|
||||
| 1.11.0 | N/A | 1.11.1 |
|
||||
|
||||
|
||||
## Upgrade on Hosting platforms
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ The following table lists the environment variables used by the Dapr runtime, CL
|
|||
| -------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| APP_ID | Your application | The id for your application, used for service discovery |
|
||||
| APP_PORT | Dapr sidecar | The port your application is listening on |
|
||||
| APP_API_TOKEN | Your application | The token used by the application to authenticate requests from Dapr API. Read [authenticate requests from Dapr using token authentication]({{< ref app-api-token >}}) for more information. |
|
||||
| APP_API_TOKEN | Your application | The token used by the application to authenticate requests from Dapr API. Read [authenticate requests from Dapr using token authentication]({{< ref app-api-token >}}) for more information. |
|
||||
| DAPR_HTTP_PORT | Your application | The HTTP port that the Dapr sidecar is listening on. Your application should use this variable to connect to Dapr sidecar instead of hardcoding the port value. Set by the Dapr CLI run command for self-hosted or injected by the `dapr-sidecar-injector` into all the containers in the pod. |
|
||||
| DAPR_GRPC_PORT | Your application | The gRPC port that the Dapr sidecar is listening on. Your application should use this variable to connect to Dapr sidecar instead of hardcoding the port value. Set by the Dapr CLI run command for self-hosted or injected by the `dapr-sidecar-injector` into all the containers in the pod. |
|
||||
| DAPR_API_TOKEN | Dapr sidecar | The token used for Dapr API authentication for requests from the application. [Enable API token authentication in Dapr]({{< ref api-token >}}). |
|
||||
|
|
@ -24,4 +24,6 @@ The following table lists the environment variables used by the Dapr runtime, CL
|
|||
| DAPR_HELM_REPO_PASSWORD | A password for a private Helm chart |The password required to access the private Dapr helm chart. If it can be accessed publicly, this env variable does not need to be set|
|
||||
| OTEL_EXPORTER_OTLP_ENDPOINT | OpenTelemetry Tracing | Sets the Open Telemetry (OTEL) server address, turns on tracing. (Example: `http://localhost:4318`) |
|
||||
| OTEL_EXPORTER_OTLP_INSECURE | OpenTelemetry Tracing | Sets the connection to the endpoint as unencrypted. (`true`, `false`) |
|
||||
| OTEL_EXPORTER_OTLP_PROTOCOL | OpenTelemetry Tracing | The OTLP protocol to use Transport protocol. (`grpc`, `http/protobuf`, `http/json`) |
|
||||
| OTEL_EXPORTER_OTLP_PROTOCOL | OpenTelemetry Tracing | The OTLP protocol to use Transport protocol. (`grpc`, `http/protobuf`, `http/json`) |
|
||||
| DAPR_COMPONENTS_SOCKETS_FOLDER | Dapr runtime and the .NET, Go, and Java pluggable component SDKs | The location or path where Dapr looks for Pluggable Components Unix Domain Socket files. If unset this location defaults to `/tmp/dapr-components-sockets` |
|
||||
| DAPR_COMPONENTS_SOCKETS_EXTENSION | .NET and Java pluggable component SDKs | A per-SDK configuration that indicates the default file extension applied to socket files created by the SDKs. Not a Dapr-enforced behavior. |
|
||||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Component schema"
|
||||
linkTitle: "Component schema"
|
||||
weight: 100
|
||||
description: "The basic schema for a Dapr component"
|
||||
title: "Component spec"
|
||||
linkTitle: "Component"
|
||||
weight: 1000
|
||||
description: "The basic spec for a Dapr component"
|
||||
---
|
||||
|
||||
Dapr defines and registers components using a [CustomResourceDefinition](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). All components are defined as a CRD and can be applied to any hosting environment where Dapr is running, not just Kubernetes.
|
||||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
type: docs
|
||||
title: "HTTPEndpoint spec"
|
||||
linkTitle: "HTTPEndpoint spec"
|
||||
description: "The HTTPEndpoint resource spec"
|
||||
weight: 300
|
||||
linkTitle: "HTTPEndpoint"
|
||||
description: "The basic spec for a Dapr HTTPEndpoint resource"
|
||||
weight: 4000
|
||||
aliases:
|
||||
- "/operations/httpEndpoints/"
|
||||
---
|
||||
|
|
@ -0,0 +1,63 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Resiliency spec"
|
||||
linkTitle: "Resiliency"
|
||||
weight: 3000
|
||||
description: "The basic spec for a Dapr resiliency resource"
|
||||
---
|
||||
|
||||
The `Resiliency` Dapr resource allows you to define and apply fault tolerance resiliency policies. Resiliency specs are applied when the Dapr sidecar starts.
|
||||
|
||||
```yml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Resiliency
|
||||
metadata:
|
||||
name: <REPLACE-WITH-RESOURCE-NAME>
|
||||
version: v1alpha1
|
||||
scopes:
|
||||
- <REPLACE-WITH-SCOPED-APPIDS>
|
||||
spec:
|
||||
policies: # Required
|
||||
timeouts: # Replace with any unique name
|
||||
timeoutName: <REPLACE-WITH-TIME-VALUE>
|
||||
retries:
|
||||
retryName: # Replace with any unique name
|
||||
policy: <REPLACE-WITH-VALUE>
|
||||
duration: <REPLACE-WITH-VALUE>
|
||||
maxInterval: <REPLACE-WITH-VALUE>
|
||||
maxRetries: <REPLACE-WITH-VALUE>
|
||||
circuitBreakers:
|
||||
circuitBreakerName: # Replace with any unique name
|
||||
maxRequests: <REPLACE-WITH-VALUE>
|
||||
timeout: <REPLACE-WITH-VALUE>
|
||||
trip: <REPLACE-WITH-CONSECUTIVE-FAILURE-VALUE>
|
||||
targets: # Required
|
||||
apps:
|
||||
appID: # Replace with scoped app ID
|
||||
timeout: <REPLACE-WITH-TIMEOUT-NAME>
|
||||
retry: <REPLACE-WITH-RETRY-NAME>
|
||||
circuitBreaker: <REPLACE-WITH-CIRCUIT-BREAKER-NAME>
|
||||
actors:
|
||||
myActorType:
|
||||
timeout: <REPLACE-WITH-TIMEOUT-NAME>
|
||||
retry: <REPLACE-WITH-RETRY-NAME>
|
||||
circuitBreaker: <REPLACE-WITH-CIRCUIT-BREAKER-NAME>
|
||||
circuitBreakerCacheSize: <REPLACE-WITH-VALUE>
|
||||
components:
|
||||
componentName: # Replace with your component name
|
||||
outbound:
|
||||
timeout: <REPLACE-WITH-TIMEOUT-NAME>
|
||||
retry: <REPLACE-WITH-RETRY-NAME>
|
||||
circuitBreaker: <REPLACE-WITH-CIRCUIT-BREAKER-NAME>
|
||||
```
|
||||
|
||||
## Spec fields
|
||||
|
||||
| Field | Required | Details | Example |
|
||||
|--------------------|:--------:|---------|---------|
|
||||
| policies | Y | The configuration of resiliency policies, including: <br><ul><li>`timeouts`</li><li>`retries`</li><li>`circuitBreakers`</li></ul> <br> [See more examples with all of the built-in policies]({{< ref policies.md >}}) | timeout: `general`<br>retry: `retryForever`<br>circuit breaker: `simpleCB` |
|
||||
| targets | Y | The configuration for the applications, actors, or components that use the resiliency policies. <br>[See more examples in the resiliency targets guide]({{< ref targets.md >}}) | `apps` <br>`components`<br>`actors` |
|
||||
|
||||
|
||||
## Related links
|
||||
[Learn more about resiliency policies and targets]({{< ref resiliency-overview.md >}})
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Subscription spec"
|
||||
linkTitle: "Subscription"
|
||||
weight: 2000
|
||||
description: "The basic spec for a Dapr subscription"
|
||||
---
|
||||
|
||||
The `Subscription` Dapr resource allows you to subscribe declaratively to a topic using an external component YAML file. This guide demonstrates two subscription API versions:
|
||||
|
||||
- `v2alpha` (default spec)
|
||||
- `v1alpha1` (deprecated)
|
||||
|
||||
## `v2alpha1`
|
||||
|
||||
The following is the basic `v2alpha1` spec for a `Subscription` resource. `v2alpha1` is the default spec for the subscription API.
|
||||
|
||||
```yml
|
||||
apiVersion: dapr.io/v2alpha1
|
||||
kind: Subscription
|
||||
metadata:
|
||||
name: <REPLACE-WITH-NAME>
|
||||
spec:
|
||||
version: v2alpha1
|
||||
topic: <REPLACE-WITH-TOPIC-NAME> # Required
|
||||
routes: # Required
|
||||
- rules:
|
||||
- match: <REPLACE-WITH-EVENT-TYPE>
|
||||
path: <REPLACE-WITH-PATH>
|
||||
pubsubname: <REPLACE-WITH-PUBSUB-NAME> # Required
|
||||
deadlettertopic: <REPLACE-WITH-TOPIC-NAME> # Optional
|
||||
bulksubscribe: # Optional
|
||||
- enabled: <REPLACE-WITH-TOPIC-NAME>
|
||||
- maxmessages: <REPLACE-WITH-TOPIC-NAME>
|
||||
- maxawaitduration: <REPLACE-WITH-TOPIC-NAME>
|
||||
scopes:
|
||||
- <REPLACE-WITH-SCOPED-APPIDS>
|
||||
```
|
||||
|
||||
### Spec fields
|
||||
|
||||
| Field | Required | Details | Example |
|
||||
|--------------------|:--------:|---------|---------|
|
||||
| topic | Y | The name of the topic to which your component subscribes. | `orders` |
|
||||
| routes | Y | The routes configuration for this topic, including specifying the condition for sending a message to a specific path. Includes the following fields: <br><ul><li>match: _Optional._ The CEL expression used to match the event. If not specified, the route is considered the default. </li><li>path: The path for events that match this rule. </li></ul>The endpoint to which all topic messages are sent. | `match: event.type == "widget"` <br>`path: /widgets` |
|
||||
| pubsubname | N | The name of your pub/sub component. | `pubsub` |
|
||||
| deadlettertopic | N | The name of the dead letter topic that forwards undeliverable messages. | `poisonMessages` |
|
||||
| bulksubscribe | N | Enable bulk subscribe properties. | `true`, `false` |
|
||||
|
||||
|
||||
## `v1alpha1`
|
||||
|
||||
The following is the basic version `v1alpha1` spec for a `Subscription` resource. `v1alpha1` is now deprecated.
|
||||
|
||||
```yml
|
||||
apiVersion: dapr.io/v1alpha1
|
||||
kind: Subscription
|
||||
metadata:
|
||||
name: <REPLACE-WITH-RESOURCE-NAME>
|
||||
spec:
|
||||
version: v1alpha1
|
||||
topic: <REPLACE-WITH-TOPIC-NAME> # Required
|
||||
route: <REPLACE-WITH-ROUTE-NAME> # Required
|
||||
pubsubname: <REPLACE-WITH-PUBSUB-NAME> # Required
|
||||
deadLetterTopic: <REPLACE-WITH-DEAD-LETTER-TOPIC-NAME> # Optional
|
||||
bulkSubscribe: # Optional
|
||||
- enabled: <REPLACE-WITH-BOOLEAN-VALUE>
|
||||
- maxmessages: <REPLACE-WITH-VALUE>
|
||||
- maxawaitduration: <REPLACE-WITH-VALUE>
|
||||
scopes:
|
||||
- <REPLACE-WITH-SCOPED-APPIDS>
|
||||
```
|
||||
|
||||
### Spec fields
|
||||
|
||||
| Field | Required | Details | Example |
|
||||
|--------------------|:--------:|---------|---------|
|
||||
| topic | Y | The name of the topic to which your component subscribes. | `orders` |
|
||||
| route | Y | The endpoint to which all topic messages are sent. | `/checkout` |
|
||||
| pubsubname | N | The name of your pub/sub component. | `pubsub` |
|
||||
| deadlettertopic | N | The name of the dead letter topic that forwards undeliverable messages. | `poisonMessages` |
|
||||
| bulksubscribe | N | Enable bulk subscribe properties. | `true`, `false` |
|
||||
|
||||
## Related links
|
||||
- [Learn more about the declarative subscription method]({{< ref "subscription-methods.md#declarative-subscriptions" >}})
|
||||
- [Learn more about dead letter topics]({{< ref pubsub-deadletter.md >}})
|
||||
- [Learn more about routing messages]({{< ref "howto-route-messages.md#declarative-subscription" >}})
|
||||
- [Learn more about bulk subscribing]({{< ref pubsub-bulk.md >}})
|
||||
|
|
@ -1 +1 @@
|
|||
{{- if .Get "short" }}1.11{{ else if .Get "long" }}1.11.0{{ else if .Get "cli" }}1.11.0{{ else }}1.11.0{{ end -}}
|
||||
{{- if .Get "short" }}1.11{{ else if .Get "long" }}1.11.1{{ else if .Get "cli" }}1.11.0{{ else }}1.11.1{{ end -}}
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ spec:
|
|||
spec:
|
||||
containers:
|
||||
- name: otel-collector
|
||||
image: otel/opentelemetry-collector-contrib:0.50.0
|
||||
image: otel/opentelemetry-collector-contrib:0.77.0
|
||||
command:
|
||||
- "/otelcol-contrib"
|
||||
- "--config=/conf/otel-collector-config.yaml"
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 56 KiB After Width: | Height: | Size: 31 KiB |
Loading…
Reference in New Issue