Skip to content

Commit

Permalink
Merge pull request #3910 from JoshVanL/preview-feature-component-hot-…
Browse files Browse the repository at this point in the history
…reloading

Component Hot Reloading
  • Loading branch information
hhunter-ms authored Jan 11, 2024
2 parents 4822030 + be597e9 commit cc3d110
Show file tree
Hide file tree
Showing 3 changed files with 22 additions and 5 deletions.
8 changes: 8 additions & 0 deletions daprdocs/content/en/concepts/components-concept.md
Original file line number Diff line number Diff line change
Expand Up @@ -52,6 +52,14 @@ For example:

For more information read [Pluggable components overview]({{< ref "pluggable-components-overview" >}})

## Hot Reloading

With the [`HotReload` feature enabled]({{< ref "support-preview-features.md" >}}), components are able to be "hot reloaded" at runtime.
This means that you can update component configuration without restarting the Dapr runtime.
Component reloading occurs when a component resource is created, updated, or deleted, either in the Kubernetes API or in self-hosted mode when a file is changed in the `resources` directory.
When a component is updated, the component is first closed, and then reinitialized using the new configuration.
The component is unavailable for a short period of time during reload and reinitialization.

## Available component types

The following are the component types provided by Dapr:
Expand Down
17 changes: 13 additions & 4 deletions daprdocs/content/en/operations/components/component-updates.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,18 +6,27 @@ weight: 300
description: "Updating deployed components used by applications"
---

When making an update to an existing deployed component used by an application, Dapr does not update the component automatically. The Dapr sidecar needs to be restarted in order to pick up the latest version of the component. How this done depends on the hosting environment.
When making an update to an existing deployed component used by an application, Dapr does not update the component automatically unless the `HotReload` feature gate is enabled.
The Dapr sidecar needs to be restarted in order to pick up the latest version of the component.
How this is done depends on the hosting environment.

{{% alert title="Note" color="primary" %}}
Dapr can be made to "hot reload" components, where updates are picked up automatically without needing a restart.
This is enabled by via the [`HotReload` feature gate]({{< ref "support-preview-features.md" >}}).
All component types are supported for hot reloading.
This feature is currently in preview.
{{% /alert %}}

## Kubernetes

When running in Kubernetes, the process of updating a component involves two steps:

1. Applying the new component YAML to the desired namespace
2. Performing a [rollout restart operation](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#updating-resources) on your deployments to pick up the latest component
1. Apply the new component YAML to the desired namespace
1. Unless the [`HotReload` feature gate is enabled]({{< ref "support-preview-features.md" >}}), perform a [rollout restart operation](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#updating-resources) on your deployments to pick up the latest component

## Self Hosted

When running in Self Hosted mode, the process of updating a component involves a single step of stopping the `daprd` process and starting it again to pick up the latest component.
Unless the [`HotReload` feature gate is enabled]({{< ref "support-preview-features.md" >}}), the process of updating a component involves a single step of stopping and restarting the `daprd` process to pick up the latest component.

## Further reading
- [Components concept]({{< ref components-concept.md >}})
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -22,4 +22,4 @@ For CLI there is no explicit opt-in, just the version that this was first made a
| **Service invocation for non-Dapr endpoints** | Allow the invocation of non-Dapr endpoints by Dapr using the [Service invocation API]({{< ref service_invocation_api.md >}}). Read ["How-To: Invoke Non-Dapr Endpoints using HTTP"]({{< ref howto-invoke-non-dapr-endpoints.md >}}) for more information. | N/A | [Service invocation API]({{< ref service_invocation_api.md >}}) | v1.11 |
| **Actor State TTL** | Allow actors to save records to state stores with Time To Live (TTL) set to automatically clean up old data. In its current implementation, actor state with TTL may not be reflected correctly by clients, read [Actor State Transactions]({{< ref actors_api.md >}}) for more information. | `ActorStateTTL` | [Actor State Transactions]({{< ref actors_api.md >}}) | v1.11 |
| **Transactional Outbox** | Allows state operations for inserts and updates to be published to a configured pub/sub topic using a single transaction across the state store and the pub/sub | N/A | [Transactional Outbox Feature]({{< ref howto-outbox.md >}}) | v1.12 |

| **Component Hot Reloading** | Allows for Dapr-loaded components to be "hot reloaded". A component spec is reloaded when it is created/updated/deleted in Kubernetes or on file when running in self-hosted mode.| `HotReload`| [Hot Reloading]({{< ref components-concept.md >}}) | v1.13 |

0 comments on commit cc3d110

Please sign in to comment.