review from Mark and Cassie pt 2

Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>

daprdocs/content/en/concepts/dapr-services/placement.md

@@ -13,7 +13,9 @@ The Placement service Docker container is started automatically as part of [`dap
 
 ## Kubernetes mode
 
-The Placement service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
+The Placement service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. You can run Placement in high availability (HA) mode. [Learn more about setting HA mode in your Kubernetes service.]({{< ref "kubernetes-production.md#individual-service-ha-helm-configuration" >}})
+
+For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
 
 ## Placement tables
 

daprdocs/content/en/concepts/dapr-services/scheduler.md

@@ -11,7 +11,11 @@ The diagram below shows how the Scheduler service is used via the jobs API when
 
 <img src="/images/scheduler/scheduler-architecture.png" alt="Diagram showing the Scheduler control plane service and the jobs API">
 
-The Scheduler service is used by default for [actor scheduler reminders]({{< ref "jobs-overview.md#actor-reminders" >}}) where actor reminders, which are also used by workflows, are stored in the Scheduler service as opposed to the Placement service.
+## Actor reminders
+
+Prior to Dapr v1.15, [actor reminders]({{< ref "actors-timers-reminders.md#actor-reminders" >}}) were run using the Placement service. Now, by default, the [`SchedulerReminders` feature flag]({{< ref "support-preview-features.md#current-preview-features" >}}) is set to `true`, and all new actor reminders you create are run using the Scheduler service to make them more scalable.
+
+Once you deploy Dapr v1.15, any _existing_ actor reminders are migrated from the Placement service to the Scheduler service. You can prevent this migration by setting the `SchedulerReminders` flag to `false`.
 
 ## Self-hosted mode
 
@@ -19,7 +23,7 @@ The Scheduler service Docker container is started automatically as part of `dapr
 
 ## Kubernetes mode
 
-The Scheduler service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. You can run Scheduler in high availability (HA) mode. [Learn more about setting HA mode in your Kubernetes service.]({{< ref "kubernetes-production.md#high-availability-mode" >}})
+The Scheduler service is deployed as part of `dapr init -k`, or via the Dapr Helm charts. You can run Scheduler in high availability (HA) mode. [Learn more about setting HA mode in your Kubernetes service.]({{< ref "kubernetes-production.md#individual-service-ha-helm-configuration" >}})
 
 For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
 

daprdocs/content/en/developing-applications/building-blocks/actors/actors-timers-reminders.md

@@ -107,6 +107,10 @@ Refer [api spec]({{< ref "actors_api.md#invoke-timer" >}}) for more details.
 
 ## Actor reminders
 
+{{% alert title="Note" color="primary" %}}
+In Dapr v1.15, actor reminders are stored by default in the [Scheduler service]({{< ref "scheduler.md#actor-reminders" >}}).
+{{% /alert %}}
+
 Reminders are a mechanism to trigger *persistent* callbacks on an actor at specified times. Their functionality is similar to timers. But unlike timers, reminders are triggered under all circumstances until the actor explicitly unregisters them or the actor is explicitly deleted or the number in invocations is exhausted. Specifically, reminders are triggered across actor deactivations and failovers because the Dapr actor runtime persists the information about the actors' reminders using Dapr actor state provider.
 
 You can create a persistent reminder for an actor by calling the HTTP/gRPC request to Dapr as shown below, or via Dapr SDK.

daprdocs/content/en/developing-applications/building-blocks/jobs/jobs-overview.md

@@ -59,14 +59,6 @@ The jobs API provides several features to make it easy for you to schedule jobs.
 
 The Scheduler service enables the scheduling of jobs to scale across multiple replicas, while guaranteeing that a job is only triggered by 1 scheduler service instance.
 
-### Actor reminders
-
-Actors have reminders; the Scheduler service is used by default for actor reminders (which are also used by workflows) to make them more scalable. 
-
-> **Note:** In earlier releases, the Placement service was used for actor reminders. This is no longer recommended. 
-
-The `SchedulerReminders` preview feature defaults to `true`. To disable actor scheduler reminders, you can set it to `false`.
-
 ## Try out the jobs API
 
 You can try out the jobs API in your application. After [Dapr is installed]({{< ref install-dapr-cli.md >}}), you can begin using the jobs API, starting with [the How-to: Schedule jobs guide]({{< ref howto-schedule-and-handle-triggered-jobs.md >}}).

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

@@ -231,6 +231,19 @@ You can install Dapr on Kubernetes using a Helm v3 chart.
     --wait
     ```
 
+   To install in **high availability** mode and scale select services independently of global:
+
+   ```bash
+       helm upgrade --install dapr dapr/dapr \
+    --version={{% dapr-latest-version short="true" %}} \
+    --namespace dapr-system \
+    --create-namespace \
+    --set global.ha.enabled=false \
+    --set dapr_scheduler.ha=true \
+    --set dapr_placement.ha=true \
+    --wait
+   ```
+   
 See [Guidelines for production ready deployments on Kubernetes]({{< ref kubernetes-production.md >}}) for more information on installing and upgrading Dapr using Helm.
 
 ### (optional) Install the Dapr dashboard as part of the control plane

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

@@ -95,15 +95,24 @@ For a new Dapr deployment, HA mode can be set with both:
 
 For an existing Dapr deployment, [you can enable HA mode in a few extra steps]({{< ref "#enabling-high-availability-in-an-existing-dapr-deployment" >}}).
 
-### Scheduler service HA configuration
+### Individual service HA Helm configuration
 
-As of Dapr 1.15, the scheduler `dapr_scheduler.ha` flag scales schedulers to three instances independently of the `global.ha.enabled` flag. Default is one instance, meaning HA for schedulers is not default.
+You can configure HA mode via Helm across all services by setting the `global.ha.enabled` flag to `true`. By default, `--set global.ha.enabled=true` is fully respected and cannot be overridden, making it impossible to simultaneously have either the placement or scheduler service as a single instance. 
 
-`global.ha.enabled` set to `true` is fully respected and cannot be overridden by setting the local HA flag to `false`.
+> **Note:** HA for scheduler and placement services is not the default setting. 
 
-To scale the schedulers to three instancers, set `global.ha.enabled` to false and `dapr_scheduler.ha` to true. 
+To scale scheduler and placement to three instances independently of the `global.ha.enabled` flag, set `global.ha.enabled` to `false` and `dapr_scheduler.ha` and `dapr_placement.ha` to `true`. For example:
 
-This flag can be set via Helm with `--set dapr_scheduler.ha=true`.
+   ```bash
+   helm upgrade --install dapr dapr/dapr \
+    --version={{% dapr-latest-version short="true" %}} \
+    --namespace dapr-system \
+    --create-namespace \
+    --set global.ha.enabled=false \
+    --set dapr_scheduler.ha=true \
+    --set dapr_placement.ha=true \
+    --wait
+   ```
 
 ## Setting cluster critical priority class name for control plane services
 

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

@@ -22,4 +22,4 @@ 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  |
-| **Scheduler Actor Reminders** | Scheduler actor reminders are actor reminders stored in the Scheduler control plane service, as opposed to the Placement control plane service actor reminder system. The `SchedulerReminders` preview feature defaults to `true`, but you can disable Scheduler actor reminders by setting it to `false`.  | `SchedulerReminders`| [Scheduler actor reminders]({{< ref "jobs-overview.md#actor-reminders" >}}) | v1.14  |
+| **Scheduler Actor Reminders** | Scheduler actor reminders are actor reminders stored in the Scheduler control plane service, as opposed to the Placement control plane service actor reminder system. The `SchedulerReminders` preview feature defaults to `true`, but you can disable Scheduler actor reminders by setting it to `false`.  | `SchedulerReminders`| [Scheduler actor reminders]({{< ref "scheduler.md#actor-reminders" >}}) | v1.14  |