Skip to content

Commit 60a756c

Browse files
authored
Merge branch 'v1.18' into hot-reloading-configuration
2 parents 3e12573 + 08600f3 commit 60a756c

15 files changed

Lines changed: 245 additions & 8 deletions

File tree

.github/workflows/website-v1-18.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ on:
1212

1313
jobs:
1414
build_and_deploy_job:
15-
if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
15+
if: github.event.action != 'closed'
1616
runs-on: ubuntu-latest
1717
name: Build and Deploy Job
1818
steps:

daprdocs/content/en/developing-ai/dapr-agents/_index.md

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,14 +3,18 @@ type: docs
33
title: "Dapr Agents"
44
linkTitle: "Dapr Agents"
55
weight: 25
6-
description: "A framework for building durable and resilient AI agent systems at scale"
6+
description: "A production-ready framework for building durable and resilient AI agent systems at scale"
77
aliases:
88
- /developing-applications/dapr-agents
99
---
1010

1111
![Concepts Agents](/images/dapr-agents/agents-blue.png)
1212

13+
{{% alert title="Dapr Agents v1.0 — Generally Available" color="primary" %}}
14+
Dapr Agents is **v1.0** and production ready. The framework provides stable APIs, enterprise-grade reliability, and support for building and operating LLM-powered agentic systems at scale.
15+
{{% /alert %}}
16+
1317
### What is Dapr Agents?
1418

1519
Dapr Agents is a Python framework for building LLM-powered autonomous agentic applications using Dapr's distributed systems capabilities. It provides tools for creating AI agents that can execute durable tasks, make decisions, and collaborate through workflows, while leveraging Dapr's state management, messaging, and observability features for reliable execution at scale.
16-
20+

daprdocs/content/en/developing-ai/dapr-agents/dapr-agents-introduction.md

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,9 @@ aliases:
1010

1111
![Agent Overview](/images/dapr-agents/concepts-agents-overview.png)
1212

13+
{{% alert title="Dapr Agents v1.0 — Generally Available" color="primary" %}}
14+
Dapr Agents **v1.0** is production ready with stable APIs and enterprise-grade support for agentic workloads.
15+
{{% /alert %}}
1316

1417
Dapr Agents is a developer framework for building durable and resilient AI agent systems powered by Large Language Models (LLMs). Built on the battle-tested Dapr project, it enables developers to create autonomous systems that have identity, reason through problems, make dynamic decisions, and collaborate seamlessly. It includes built-in observability and stateful workflow execution to ensure agentic workflows complete successfully, regardless of complexity. Whether you're developing single-agent applications or complex multi-agent workflows, Dapr Agents provides the infrastructure for intelligent, adaptive systems that scale across environments.
1518

@@ -89,4 +92,4 @@ These capabilities enable teams to monitor agent performance, secure multi-agent
8992

9093
Whether you're interested in enhancing the framework, adding new integrations, or improving documentation, we welcome contributions from the community.
9194

92-
For development setup and guidelines, see our [Contributor Guide]({{% ref "contributing/dapr-agents.md" %}}).
95+
For development setup and guidelines, see our [Contributor Guide]({{% ref "contributing/dapr-agents.md" %}}).

daprdocs/content/en/developing-ai/dapr-agents/dapr-agents-why.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ aliases:
88
- /developing-applications/dapr-agents/dapr-agents-why
99
---
1010

11-
Dapr Agents is an open-source framework for building and orchestrating LLM-based autonomous agents that leverages Dapr's proven distributed systems foundation. Unlike other agentic frameworks that require developers to build infrastructure from scratch, Dapr Agents enables teams to focus on agent intelligence by providing enterprise-grade scalability, state management, and messaging capabilities out of the box. This approach eliminates the complexity of recreating distributed system fundamentals while delivering agentic workflows powered by Dapr.
11+
Dapr Agents is a production-ready, open-source framework (v1.0) for building and orchestrating LLM-based autonomous agents that leverages Dapr's proven distributed systems foundation. Unlike other agentic frameworks that require developers to build infrastructure from scratch, Dapr Agents enables teams to focus on agent intelligence by providing enterprise-grade scalability, state management, and messaging capabilities out of the box. This approach eliminates the complexity of recreating distributed system fundamentals while delivering agentic workflows powered by Dapr.
1212

1313
### Challenges with Existing Frameworks
1414

@@ -134,4 +134,4 @@ By building on Dapr, platform and infrastructure teams can apply Dapr's [resilie
134134

135135
### Vendor-Neutral and Open Source
136136

137-
As part of the **CNCF**, Dapr Agents is vendor-neutral, eliminating concerns about lock-in, intellectual property risks, or proprietary restrictions. Organizations gain full flexibility and control over their AI applications using open-source software they can audit and contribute to.
137+
As part of the **CNCF**, Dapr Agents is vendor-neutral, eliminating concerns about lock-in, intellectual property risks, or proprietary restrictions. Organizations gain full flexibility and control over their AI applications using open-source software they can audit and contribute to.

daprdocs/content/en/operations/components/component-updates.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,8 @@ When running in Kubernetes, the process of updating a component involves two ste
2121

2222
Unless the [`HotReload` feature gate is enabled](#hot-reloading-preview-feature), the process of updating a component involves a single step of stopping and restarting the `daprd` process to pick up the latest component.
2323

24+
> **Note:** On POSIX-compatible systems (Linux, macOS), you can also send a `SIGHUP` signal to the `daprd` process to reload the runtime in-process without fully restarting it. See [Reloading configuration with SIGHUP]({{% ref "configuration-overview.md#reloading-configuration-with-sighup" %}}) for more information.
25+
2426
## Hot Reloading (Preview Feature)
2527

2628
> This feature is currently in [preview]({{% ref "preview-features.md" %}}).

daprdocs/content/en/operations/configuration/configuration-overview.md

Lines changed: 24 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -76,6 +76,7 @@ The following menu includes all of the configuration settings you can set:
7676
- [Disallow usage of certain component types](#disallow-usage-of-certain-component-types)
7777
- [Turning on preview features](#turning-on-preview-features)
7878
- [Example sidecar configuration](#example-sidecar-configuration)
79+
- [Reloading configuration with SIGHUP](#reloading-configuration-with-sighup)
7980
8081
#### Tracing
8182
@@ -380,9 +381,31 @@ spec:
380381
action: allow
381382
```
382383

384+
#### Reloading configuration with SIGHUP
385+
386+
On POSIX-compatible systems (Linux, macOS), you can reload the Dapr sidecar configuration without fully restarting the process by sending a `SIGHUP` signal to `daprd`. When `daprd` receives a `SIGHUP`, it gracefully shuts down the internal runtime and re-initializes it in-process using the current configuration file. This allows you to apply changes to configuration settings such as [tracing](#tracing), [metrics](#metrics), and [logging](#logging) without a full process restart.
387+
388+
To send a `SIGHUP` signal:
389+
390+
```bash
391+
# Using the kill command
392+
kill -SIGHUP <daprd-pid>
393+
394+
# Or using pkill
395+
pkill -HUP daprd
396+
```
397+
398+
{{% alert title="Note" color="primary" %}}
399+
During a SIGHUP reload, the Dapr sidecar is briefly unavailable while the runtime reinitializes. The sidecar will continue to handle graceful shutdown of existing connections before reloading.
400+
{{% /alert %}}
401+
402+
{{% alert title="Note" color="primary" %}}
403+
SIGHUP-based reloading is only available on POSIX-compatible systems (Linux, macOS). On Windows, a full restart of `daprd` is required to pick up configuration changes.
404+
{{% /alert %}}
405+
383406
## Control plane configuration
384407

385-
A single configuration file called `daprsystem` is installed with the Dapr control plane system services that applies global settings.
408+
A single configuration file called `daprsystem` is installed with the Dapr control plane system services that applies global settings.
386409

387410
> **This is only set up when Dapr is deployed to Kubernetes.**
388411

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

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -122,6 +122,30 @@ To scale scheduler and placement to three instances independently of the `global
122122
--wait
123123
```
124124

125+
### Spreading Placement and Scheduler replicas
126+
127+
With HA enabled, the default Helm values add pod anti-affinity so Scheduler and Placement service replicas are attempted to be scheduled across different failure domains if cluster resourcing allows. This is configured using the following Helm chart [options](https://github.com/dapr/dapr/blob/master/charts/dapr/README.md)
128+
129+
- `global.ha.topologyKey`: Kubernetes label used meaning “different domain”. Set by default to `topology.kubernetes.io/zone`.
130+
- `global.ha.podAntiAffinityPolicy`: Enables soft spreading with `preferredDuringSchedulingIgnoredDuringExecution` (the default) or hard spreading with `requiredDuringSchedulingIgnoredDuringExecution`.
131+
132+
When running in production, consider the following recommendations.
133+
134+
1. **Availability zones**: The default topology key spreads pods across zones. This limits the chance that a single zone outage removes multiple Scheduler or Placement pods at the same time.
135+
2. **Single zone, many nodes**: Zone labels are often identical across the cluster; set `topologyKey` to `kubernetes.io/hostname` to enable spreading by node.
136+
3. **Soft spreading**: The default behaviour is recommended here allowing pod scheduling to succeed when the cluster is short on zones or nodes.
137+
4. **Hard spreading**: Only use when you must never place two replicas on the same topology value. This requires as many distinct values for `topologyKey` as replicas, or pods will stay `Pending`.
138+
139+
For example, too configure hard spreading by hostname in a single-zone cluster, use the following Helm values:
140+
141+
```yaml
142+
global:
143+
ha:
144+
enabled: true
145+
topologyKey: kubernetes.io/hostname
146+
podAntiAffinityPolicy: requiredDuringSchedulingIgnoredDuringExecution
147+
```
148+
125149
## Setting cluster critical priority class name for control plane services
126150

127151
In some scenarios, nodes may have memory and/or cpu pressure and the Dapr control plane pods might get selected

daprdocs/content/en/reference/components-reference/supported-bindings/redis.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -28,6 +28,8 @@ spec:
2828
value: "true"
2929
- name: enableTLS
3030
value: "<bool>"
31+
- name: insecureSkipTLSVerify
32+
value: "<bool>"
3133
```
3234
3335
{{% alert title="Warning" color="warning" %}}
@@ -43,6 +45,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
4345
| `redisUsername` | N | Output | Username for Redis host. Defaults to empty. Make sure your redis server version is 6 or above, and have created acl rule correctly. | `"username"` |
4446
| `useEntraID` | N | Output | Implements EntraID support for Azure Cache for Redis. Before enabling this: <ul><li>The `redisHost` name must be specified in the form of `"server:port"`</li><li>TLS must be enabled</li></ul> Learn more about this setting under [Create a Redis instance > Azure Cache for Redis]({{% ref "#create-a-redis-instance" %}}) | `"true"`, `"false"` |
4547
| `enableTLS` | N | Output | If the Redis instance supports TLS with public certificates it can be configured to enable or disable TLS. Defaults to `"false"` | `"true"`, `"false"` |
48+
| `insecureSkipTLSVerify` | N | Output | Skip TLS certificate verification when `enableTLS` is `"true"`. Only use for testing. Defaults to `"false"` | `"true"`, `"false"` |
4649
| `clientCert` | N | Output | The content of the client certificate, used for Redis instances that require client-side certificates. Must be used with `clientKey` and `enableTLS` must be set to true. It is recommended to use a secret store as described [here]({{% ref component-secrets.md %}}) | `"----BEGIN CERTIFICATE-----\nMIIC..."` |
4750
| `clientKey` | N | Output | The content of the client private key, used in conjunction with `clientCert` for authentication. It is recommended to use a secret store as described [here]({{% ref component-secrets.md %}}) | `"----BEGIN PRIVATE KEY-----\nMIIE..."` |
4851
| `failover` | N | Output | Property to enable failover configuration. Needs sentinelMasterName to be set. When enabled, redisHost should contain the sentinel addresses. Defaults to `"false"` | `"true"`, `"false"`
Lines changed: 157 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,157 @@
1+
---
2+
type: docs
3+
title: "Kubernetes ConfigMap"
4+
linkTitle: "Kubernetes ConfigMap"
5+
description: Detailed information on the Kubernetes ConfigMap configuration store component
6+
---
7+
8+
## Component format
9+
10+
To set up a Kubernetes ConfigMap configuration store, create a component of type `configuration.kubernetes`. See [this guide]({{% ref "howto-manage-configuration.md#configure-a-dapr-configuration-store" %}}) on how to create and apply a configuration store configuration.
11+
12+
```yaml
13+
apiVersion: dapr.io/v1alpha1
14+
kind: Component
15+
metadata:
16+
name: <NAME>
17+
spec:
18+
type: configuration.kubernetes
19+
version: v1
20+
metadata:
21+
- name: configMapName
22+
value: "<CONFIGMAP_NAME>"
23+
# Optional: path to kubeconfig (only needed when running outside the cluster)
24+
#- name: kubeconfigPath
25+
# value: "/path/to/kubeconfig"
26+
# Optional: informer resync period
27+
#- name: resyncPeriod
28+
# value: "0"
29+
```
30+
31+
## Spec metadata fields
32+
33+
| Field | Required | Details | Example |
34+
|-------|:--------:|---------|---------|
35+
| `configMapName` | Y | The name of the Kubernetes ConfigMap to use as the configuration source. Must be a valid [RFC 1123](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-label-names) DNS label name. | `"my-app-config"` |
36+
| `kubeconfigPath` | N | Path to a kubeconfig file. When running inside a Kubernetes cluster (the typical case), this is not needed. When running outside the cluster, it falls back to the `KUBECONFIG` environment variable, then to `~/.kube/config`. | `"/path/to/kubeconfig"` |
37+
| `resyncPeriod` | N | How often the informer fully re-syncs the ConfigMap state from the API server as a consistency safety net, independent of watch events. Set to `"0"` (default) to disable periodic resync and rely solely on watch events. | `"10m"` |
38+
39+
## Set up a Kubernetes ConfigMap as Configuration Store
40+
41+
The Kubernetes ConfigMap configuration store requires no external infrastructure beyond the Kubernetes cluster itself.
42+
43+
### Prerequisites
44+
45+
- A running Kubernetes cluster
46+
- The Dapr sidecar must have RBAC permissions to `get`, `list`, and `watch` ConfigMaps in the target namespace
47+
48+
### 1. Create the ConfigMap
49+
50+
Create a ConfigMap that holds your configuration data:
51+
52+
```bash
53+
kubectl create configmap my-app-config \
54+
--from-literal=log.level=info \
55+
--from-literal=feature.enable-v2=true \
56+
--from-literal=database.pool-size=10
57+
```
58+
59+
Or using a YAML manifest:
60+
61+
```yaml
62+
apiVersion: v1
63+
kind: ConfigMap
64+
metadata:
65+
name: my-app-config
66+
namespace: default
67+
data:
68+
log.level: "info"
69+
feature.enable-v2: "true"
70+
database.pool-size: "10"
71+
```
72+
73+
### 2. Configure RBAC
74+
75+
The Dapr sidecar's service account needs permission to access ConfigMaps. Create a Role and RoleBinding:
76+
77+
```yaml
78+
apiVersion: rbac.authorization.k8s.io/v1
79+
kind: Role
80+
metadata:
81+
name: dapr-configmap-reader
82+
namespace: default
83+
rules:
84+
- apiGroups: [""]
85+
resources: ["configmaps"]
86+
verbs: ["get", "list", "watch"]
87+
---
88+
apiVersion: rbac.authorization.k8s.io/v1
89+
kind: RoleBinding
90+
metadata:
91+
name: dapr-configmap-reader-binding
92+
namespace: default
93+
subjects:
94+
- kind: ServiceAccount
95+
name: default
96+
namespace: default
97+
roleRef:
98+
kind: Role
99+
name: dapr-configmap-reader
100+
apiGroup: rbac.authorization.k8s.io
101+
```
102+
103+
{{% alert title="Note" color="primary" %}}
104+
If you installed Dapr using the Helm chart with default settings, the Dapr sidecar service account may already have sufficient permissions. Verify your cluster's RBAC configuration.
105+
{{% /alert %}}
106+
107+
### 3. Apply the component
108+
109+
Apply the Dapr component configuration:
110+
111+
```yaml
112+
apiVersion: dapr.io/v1alpha1
113+
kind: Component
114+
metadata:
115+
name: myconfigstore
116+
spec:
117+
type: configuration.kubernetes
118+
version: v1
119+
metadata:
120+
- name: configMapName
121+
value: "my-app-config"
122+
```
123+
124+
## How it works
125+
126+
### Data model
127+
128+
Each key in the ConfigMap's `data` field becomes a configuration item. The ConfigMap's `resourceVersion` (assigned by Kubernetes) is used as the version for all items.
129+
130+
Keys in the `binaryData` field are also supported. Their values are returned as base64-encoded strings with `"encoding": "base64"` in the item metadata.
131+
132+
### Subscriptions
133+
134+
When you subscribe to configuration changes, the component uses a [Kubernetes SharedIndexInformer](https://pkg.go.dev/k8s.io/client-go/tools/cache#SharedIndexInformer) with a field selector scoped to the specific ConfigMap. This means:
135+
136+
- Only changes to the watched ConfigMap generate API traffic
137+
- Changes are detected in near real-time via the Kubernetes watch API
138+
- Only changed keys are included in update notifications
139+
140+
When a key is deleted from the ConfigMap, the notification includes `"deleted": "true"` in the item's metadata with an empty value.
141+
142+
### Namespace
143+
144+
The component watches ConfigMaps in the same namespace as the Dapr sidecar. The namespace is derived from the `NAMESPACE` environment variable, which is automatically set by the Dapr sidecar injector via the Kubernetes downward API. If the variable is not set, the component defaults to `"default"`.
145+
146+
Cross-namespace ConfigMap access is not supported. This is by design to maintain Kubernetes namespace security boundaries.
147+
148+
{{% alert title="Note" color="primary" %}}
149+
ConfigMaps are not encrypted at rest by default in Kubernetes. Do not store sensitive values (passwords, API keys, tokens) in ConfigMaps. Use [Kubernetes Secrets]({{% ref "kubernetes-secret-store" %}}) or a dedicated secret store instead.
150+
{{% /alert %}}
151+
152+
## Related links
153+
154+
- [Basic schema for a Dapr component]({{% ref component-schema %}})
155+
- [Configuration building block]({{% ref configuration-api-overview %}})
156+
- Read [How-To: Manage configuration from a store]({{% ref "howto-manage-configuration" %}}) for instructions on how to use a configuration store.
157+
- [Kubernetes ConfigMap documentation](https://kubernetes.io/docs/concepts/configuration/configmap/)

daprdocs/content/en/reference/components-reference/supported-configuration-stores/redis-configuration-store.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -28,6 +28,8 @@ spec:
2828
value: "true"
2929
- name: enableTLS
3030
value: <bool>
31+
- name: insecureSkipTLSVerify
32+
value: <bool>
3133
```
3234
3335
{{% alert title="Warning" color="warning" %}}
@@ -43,6 +45,7 @@ The above example uses secrets as plain strings. It is recommended to use a secr
4345
| redisPassword | N | Output | The Redis password | `"password"` |
4446
| redisUsername | N | Output | Username for Redis host. Defaults to empty. Make sure your Redis server version is 6 or above, and have created acl rule correctly. | `"username"` |
4547
| enableTLS | N | Output | If the Redis instance supports TLS with public certificates it can be configured to enable or disable TLS. Defaults to `"false"` | `"true"`, `"false"` |
48+
| insecureSkipTLSVerify | N | Output | Skip TLS certificate verification when `enableTLS` is `"true"`. Only use for testing. Defaults to `"false"` | `"true"`, `"false"` |
4649
| clientCert | N | Output | The content of the client certificate, used for Redis instances that require client-side certificates. Must be used with `clientKey` and `enableTLS` must be set to true. It is recommended to use a secret store as described [here]({{% ref component-secrets.md %}}) | `"----BEGIN CERTIFICATE-----\nMIIC..."` |
4750
| clientKey | N | Output | The content of the client private key, used in conjunction with `clientCert` for authentication. It is recommended to use a secret store as described [here]({{% ref component-secrets.md %}}) | `"----BEGIN PRIVATE KEY-----\nMIIE..."` |
4851
| failover | N | Output | Property to enable failover configuration. Needs sentinelMasterName to be set. When enabled, redisHost should contain the sentinel addresses. Defaults to `"false"` | `"true"`, `"false"`

0 commit comments

Comments
 (0)