[1.18] HotReload: Configuration, Resiliency, and HTTPEndpoints

daprdocs/content/en/concepts/components-concept.md

@@ -60,6 +60,10 @@ Component reloading occurs when a component resource is created, updated, or del
 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.
 
+Hot reloading also extends to [Configuration]({{% ref "configuration-overview.md" %}}), [Resiliency]({{% ref "resiliency-overview.md" %}}), and HTTPEndpoint resources.
+Changes to these resource types trigger a graceful restart of the Dapr sidecar (via SIGHUP) to apply the new configuration. SIGHUP is not supported on Windows.
+See [Updating resources]({{% ref "component-updates.md" %}}) for more details.
+
 ## Available component types
 
 The following are the component types provided by Dapr:

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

@@ -1,9 +1,9 @@
 ---
 type: docs
-title: "Updating components"
-linkTitle: "Updating components"
+title: "Updating resources"
+linkTitle: "Updating resources"
 weight: 300
-description: "Updating deployed components used by applications"
+description: "Updating deployed components, configurations, resiliency, and HTTPEndpoints used by applications"
 ---
 
 When making an update to an existing deployed component used by an application, Dapr does not update the component automatically unless the [`HotReload`](#hot-reloading-preview-feature) feature gate is enabled.
@@ -26,8 +26,11 @@ Unless the [`HotReload` feature gate is enabled](#hot-reloading-preview-feature)
 > This feature is currently in [preview]({{% ref "preview-features.md" %}}).
 > Hot reloading is enabled by via the [`HotReload` feature gate]({{% ref "support-preview-features.md" %}}).
 
-Dapr can be made to "hot reload" components whereby component updates are picked up automatically without the need to restart the Dapr sidecar process or Kubernetes pod.
-This means creating, updating, or deleting a component manifest will be reflected in the Dapr sidecar during runtime.
+Dapr can be made to "hot reload" resources whereby updates are picked up automatically without the need to manually restart the Dapr sidecar process or Kubernetes pod.
+
+### Components and Subscriptions
+
+Creating, updating, or deleting a Component or Subscription manifest is reflected in the Dapr sidecar during runtime.
 
 {{% alert title="Updating Components" color="warning" %}}
 When a component is updated it is first closed, and then re-initialized using the new configuration.
@@ -46,6 +49,16 @@ Any create, update, or deletion of these component types is ignored by the sidec
 - [Actor State Stores]({{% ref "state_api.md#configuring-state-store-for-actors" %}})
 - [Workflow Backends]({{% ref "workflow-architecture.md#workflow-backend" %}})
 
+### Configurations, Resiliency, and HTTPEndpoints
+
+With the `HotReload` feature gate enabled, the Dapr sidecar also supports reloading [Configuration]({{% ref "configuration-overview.md" %}}), [Resiliency]({{% ref "resiliency-overview.md" %}}), and [HTTPEndpoint]({{% ref "service-invocation-overview.md" %}}) resources.
+
+Unlike Components and Subscriptions which are reloaded in-place, changes to these resource types trigger an automatic **graceful restart** of the Dapr sidecar process (via SIGHUP). This ensures that the new configuration is applied cleanly. Unchanged resources are detected and silently ignored, so a restart only occurs when an actual change is detected.
+
+{{% alert title="Windows" color="warning" %}}
+SIGHUP is not supported on Windows. On Windows, you must fully restart the `daprd` process to pick up changes to Configuration, Resiliency, and HTTPEndpoint resources.
+{{% /alert %}}
+
 ## Further reading
 - [Components concept]({{% ref components-concept.md %}})
 - [Reference secrets in component definitions]({{% ref component-secrets.md %}})

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

@@ -422,6 +422,12 @@ spec:
     workloadCertTTL: 24h
 ```
 
+## Hot Reloading
+
+When the [`HotReload` feature gate]({{% ref "support-preview-features" %}}) is enabled, changes to Configuration resources are automatically detected and trigger a graceful restart of the Dapr sidecar (via SIGHUP) to apply the new configuration. Unchanged Configuration resources are silently ignored. SIGHUP is not supported on Windows.
+
+See [Updating resources]({{% ref "component-updates.md" %}}) for more information.
+
 ## Next steps
 
 {{< button text="Learn about concurrency and rate limits" page="control-concurrency.md" >}}

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

@@ -173,6 +173,12 @@ spec:
           circuitBreaker: pubsubCB
 ```
 
+## Hot Reloading
+
+When the [`HotReload` feature gate]({{% ref "support-preview-features" %}}) is enabled, changes to Resiliency resources are automatically detected and trigger a graceful restart of the Dapr sidecar (via SIGHUP) to apply the updated resiliency policies. Unchanged Resiliency resources are silently ignored. SIGHUP is not supported on Windows.
+
+See [Updating resources]({{% ref "component-updates.md" %}}) for more information.
+
 ## Limitations
 
 - **Service invocation via gRPC:** Currently, resiliency policies are not supported for service invocation via gRPC.

daprdocs/content/en/operations/support/support-preview-features.md

@@ -21,5 +21,6 @@ For CLI there is no explicit opt-in, just the version that this was first made a
 | **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  |
 | **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. Ignores changes to actor state stores and workflow backends. | `HotReload`| [Hot Reloading]({{% ref components-concept.md %}}) | v1.13  |
 | **Subscription Hot Reloading** | Allows for declarative subscriptions to be "hot reloaded". A subscription is reloaded either when it is created/updated/deleted in Kubernetes, or on file in self-hosted mode. In-flight messages are unaffected when reloading. | `HotReload`| [Hot Reloading]({{% ref "subscription-methods.md#declarative-subscriptions" %}}) | v1.14  |
+| **Configuration, Resiliency, and HTTPEndpoint Hot Reloading** | Changes to Configuration, Resiliency, and HTTPEndpoint resources are automatically detected and trigger a graceful restart of the Dapr sidecar via SIGHUP. Not supported on Windows. | `HotReload`| [Hot Reloading]({{% ref "component-updates.md" %}}) | v1.18  |
 | **Workflows Clustered Deployment** | Enable Workflows to function when workflow clients communicate to multiple daprds of the same appID who are behind a loadbalancer. Only relevant when using [Dapr shared]({{% ref "kubernetes-dapr-shared" %}}) | `WorkflowsClusteredDeployment`| [Dapr Shared]({{% ref "kubernetes-dapr-shared" %}}) | v1.16  |
 | **Workflows Durable Activity Results** | If set, ensures that activity results are durably sent to the owning workflow in multi-application scenarios, even when the owning workflow application is unavailable. Unless running multiple Dapr versions, this feature gate should be enabled. Disabled by default for backwards compatibility.  | `WorkflowsRemoteActivityReminder` | [Multi-application Workflows]({{% ref "workflow-multi-app.md#durable-activity-results" %}}) | v1.17 |