[1.17] Remove reference to SchedulerReminders feature gate

As of 1.17, Dapr no longer supports the `SchedulerReminders` feature
gate meaning all actor reminders are managed via Scheduler.

PR removes all reference to it, including documentation on reminder
migration & old configuration for the legacy "state" reminders.

Signed-off-by: joshvanl <[email protected]>

Author: JoshVanL

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

@@ -10,9 +10,9 @@ The Dapr Scheduler service is used to schedule different types of jobs, running
 - Actor reminder jobs (used by the actor reminders)
 - Actor reminder jobs created by the Workflow API (which uses actor reminders)
 
-From Dapr v1.15, the Scheduler service is used by default to schedule actor reminders as well as actor reminders for the Workflow API.
-
-There is no concept of a leader Scheduler instance. All Scheduler service replicas are considered peers. All receive jobs to be scheduled for execution and the jobs are allocated between the available Scheduler service replicas for load balancing of the trigger events.
+There is no concept of a leader Scheduler instance.
+All Scheduler service replicas are considered peers.
+All receive jobs to be scheduled for execution and the jobs are allocated between the available Scheduler service replicas for load balancing of the trigger events.
 
 The diagram below shows how the Scheduler service is used via the jobs API when called from your application. All the jobs that are tracked by the Scheduler service are stored in the Etcd database.
 
@@ -21,35 +21,17 @@ The diagram below shows how the Scheduler service is used via the jobs API when
 By default, Etcd is embedded in the Scheduler service, which means that the Scheduler service runs its own instance of Etcd.
 See [Scheduler service flags]({{% ref "#flag-tuning" %}}) for more information on how to configure the Scheduler service.
 
-## Actor Reminders
-
-Prior to Dapr v1.15, [actor reminders]({{% ref "actors-timers-reminders#actor-reminders" %}}) were run using the Placement service. Now, by default, the [`SchedulerReminders` feature flag]({{% ref "support-preview-features#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.
-
-When you deploy Dapr v1.15, any _existing_ actor reminders are automatically migrated from the Actor State Store to the Scheduler service as a one time operation for each actor type. Each replica will only migrate the reminders whose actor type and id are associated with that host. This means that only when all replicas implementing an actor type are upgraded to 1.15, will all the reminders associated with that type be migrated. There will be _no_ loss of reminder triggers during the migration. However, you can prevent this migration and keep the existing actor reminders running using the Actor State Store by setting the `SchedulerReminders` flag to `false` in the application configuration file for the actor type.
-
-To confirm that the migration was successful, check the Dapr sidecar logs for the following:
-
-```sh
-Running actor reminder migration from state store to scheduler
-```
-coupled with
-```sh
-Migrated X reminders from state store to scheduler successfully
-```
-or
-```sh
-Skipping migration, no missing scheduler reminders found
-```
-
 ## Job Locality
 
 ### Default Job Behavior
 
-By default, when the Scheduler service triggers jobs, they are sent back to a single replica for the same app ID that scheduled the job in a randomly load balanced manner. This provides basic load balancing across your application's replicas, which is suitable for most use cases where strict locality isn't required.
+When the Scheduler service triggers jobs, they are sent back to a single replica for the same app ID that scheduled the job in a randomly load balanced manner.
+This provides basic load balancing across your application's replicas, which is suitable for most use cases where strict locality isn't required.
 
 ### Using Actor Reminders for Perfect Locality
 
-For users who require perfect job locality (having jobs triggered on the exact same host that created them), actor reminders provide a solution. To enforce perfect locality for a job:
+For users who require perfect job locality (having jobs triggered on the exact same host that created them), actor reminders provide a solution.
+To enforce perfect locality for a job:
 
 1. Create an actor type with a random UUID that is unique to the specific replica
 2. Use this actor type to create an actor reminder
@@ -60,7 +42,7 @@ This approach ensures that the job will always be triggered on the same host whi
 
 ### Job Failure Policy and Staging Queue
 
-When the Scheduler service triggers a job and it has a client side error, the job is retried by default with a 1s interval and 3 maximum retries. 
+When the Scheduler service triggers a job and it has a client side error, the job is retried by default with a 1s interval and 3 maximum retries.
 
 For non-client side errors, for example, when a job cannot be sent to an available Dapr sidecar at trigger time, it is placed in a staging queue within the Scheduler service. Jobs remain in this queue until a suitable sidecar instance becomes available, at which point they are automatically sent to the appropriate Dapr sidecar instance.
 
@@ -191,16 +173,20 @@ dapr scheduler delete-all actor/MyActorType
 
 ### Backup and restore jobs
 
-Export all jobs to a file:
+In production environments, it's recommended to perform periodic backups of this data at an interval that aligns with your recovery point objectives.
+The Dapr CLI provides a command for exporting all Scheduler data to a specific binary file.
+Use the `-k` flag when running in Kubernetes mode.
 
-```bash
-dapr scheduler export -o backup.bin
+```shell
+dapr scheduler export --output-file scheduler-backup.db
+dapr scheduler export -k --output-file scheduler-backup.db
 ```
 
-Re-import jobs from a backup file:
+To restore data from a backup file:
 
-```bash
-dapr scheduler import -f backup.bin
+```shell
+dapr scheduler import --input-file scheduler-backup.db
+dapr scheduler import -k --input-file scheduler-backup.db
 ```
 
 ## Monitoring Scheduler's etcd Metrics
@@ -216,7 +202,6 @@ Fine tune the embedded etcd to your needs by [reviewing and configuring the Sche
 ## Disabling the Scheduler service
 
 If you are not using any features that require the Scheduler service (Jobs API, Actor Reminders, or Workflows), you can disable it by setting `global.scheduler.enabled=false`.
-
 For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{% ref kubernetes %}}).
 
 ## Flag tuning

daprdocs/content/en/developing-applications/building-blocks/actors/actor-reentrancy.md

@@ -10,7 +10,7 @@ A core tenet of the [virtual actor pattern](https://www.microsoft.com/research/p
 
 Reentrancy solves this by allowing requests from the same chain, or context, to re-enter into an already locked actor. This proves useful in scenarios where:
 - An actor wants to call a method on itself
-- Actors are used in workflows to perform work, then call back onto the coordinating actor. 
+- Actors are used in workflows to perform work, then call back onto the coordinating actor.
 
 Examples of chains that reentrancy allows are shown below:
 

daprdocs/content/en/developing-applications/building-blocks/actors/actors-features-concepts.md

@@ -14,7 +14,7 @@ Now that you've learned about the [actor building block]({{% ref "actors-overvie
 
 Dapr actors are virtual, meaning that their lifetime is not tied to their in-memory representation. As a result, they do not need to be explicitly created or destroyed. The Dapr actor runtime automatically activates an actor the first time it receives a request for that actor ID. If an actor is not used for a period of time, the Dapr actor runtime garbage-collects the in-memory object. It will also maintain knowledge of the actor's existence should it need to be reactivated later.
 
-Invocation of actor methods, timers, and reminders reset the actor idle time. For example, a reminder firing keeps the actor active. 
+Invocation of actor methods, timers, and reminders reset the actor idle time. For example, a reminder firing keeps the actor active.
 - Actor reminders fire whether an actor is active or inactive. If fired for an inactive actor, it activates the actor first.
 - Actor timers firing reset the idle time; however, timers only fire while the actor is active.
 
@@ -101,4 +101,4 @@ The following example illustrates the above concepts. Consider an actor type tha
 
 - [Actors API reference]({{% ref actors_api %}})
 - [Actors overview]({{% ref actors-overview %}})
-- [How to: Use virtual actors in Dapr]({{% ref howto-actors %}})
+- [How to: Use virtual actors in Dapr]({{% ref howto-actors %}})

daprdocs/content/en/developing-applications/building-blocks/actors/actors-runtime-config.md

@@ -6,7 +6,7 @@ weight: 30
 description: Modify the default Dapr actor runtime configuration behavior
 ---
 
-You can modify the default Dapr actor runtime behavior using the following configuration parameters. 
+You can modify the default Dapr actor runtime behavior using the following configuration parameters.
 
 | Parameter | Description | Default |
 | --------- | ----------- | ------- |
@@ -16,7 +16,6 @@ You can modify the default Dapr actor runtime behavior using the following confi
 | `drainOngoingCallTimeout` | The duration when in the process of draining rebalanced actors. This specifies the timeout for the current active actor method to finish. If there is no current actor method call, this is ignored. | 60 seconds |
 | `drainRebalancedActors` | If true, Dapr will wait for `drainOngoingCallTimeout` duration to allow a current actor call to complete before trying to deactivate an actor. | true |
 | `reentrancy` (`ActorReentrancyConfig`) | Configure the reentrancy behavior for an actor. If not provided, reentrancy is disabled. | disabled, false |
-| `remindersStoragePartitions` | Configure the number of partitions for actor's reminders. If not provided, all reminders are saved as a single record in actor's state store. | 0 |
 | `entitiesConfig` | Configure each actor type individually with an array of configurations. Any entity specified in the individual entity configurations must also be specified in the top level `entities` field. | N/A |
 
 ## Examples
@@ -39,7 +38,6 @@ public void ConfigureServices(IServiceCollection services)
         options.ActorScanInterval = TimeSpan.FromSeconds(30);
         options.DrainOngoingCallTimeout = TimeSpan.FromSeconds(60);
         options.DrainRebalancedActors = true;
-        options.RemindersStoragePartitions = 7;
         options.ReentrancyConfig = new() { Enabled = false };
 
         // Add a configuration for a specific actor type.
@@ -81,7 +79,6 @@ const clientOptions = {
       enabled: true,
       maxStackDepth: 32,
     },
-    remindersStoragePartitions: 0,
   },
 };
 
@@ -112,7 +109,6 @@ ActorRuntime.set_actor_config(
         drain_ongoing_call_timeout=timedelta(minutes=1),
         drain_rebalanced_actors=True,
         reentrancy=ActorReentrancyConfig(enabled=False),
-        remindersStoragePartitions=7
     )
 )
 ```
@@ -134,7 +130,6 @@ ActorRuntime.getInstance().getConfig().setActorScanInterval(Duration.ofSeconds(3
 ActorRuntime.getInstance().getConfig().setDrainOngoingCallTimeout(Duration.ofSeconds(60));
 ActorRuntime.getInstance().getConfig().setDrainBalancedActors(true);
 ActorRuntime.getInstance().getConfig().setActorReentrancyConfig(false, null);
-ActorRuntime.getInstance().getConfig().setRemindersStoragePartitions(7);
 ```
 
 [See the documentation on writing actors with the Java SDK]({{% ref "java#actors" %}}).

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

@@ -10,7 +10,7 @@ aliases:
 
 Actors can schedule periodic work on themselves by registering either timers or reminders.
 
-The functionality of timers and reminders is very similar. The main difference is that Dapr actor runtime is not retaining any information about timers after deactivation, while persisting the information about reminders using Dapr actor state provider.
+The functionality of timers and reminders is very similar. The main difference is that Dapr actor runtime is not retaining any information about timers after deactivation, while persisting the information about reminders using Dapr [Scheduler]({{% ref scheduler.md %}}).
 
 This distinction allows users to trade off between light-weight but stateless timers vs. more resource-demanding but stateful reminders.
 
@@ -108,10 +108,6 @@ Refer [api spec]({{% ref "actors_api#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#actor-reminders" %}}). When upgrading to Dapr v1.15 all existing reminders are automatically migrated to the Scheduler service with no loss of reminders as a one time operation for each actor type.
-{{% /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.
@@ -146,7 +142,7 @@ Refer [api spec]({{% ref "actors_api#invoke-reminder" %}}) for more details.
 
 ## Error handling
 
-When an actor's method completes successfully, the runtime will continue to invoke the method at the specified timer or reminder schedule. However, if the method throws an exception, the runtime catches it and logs the error message in the Dapr sidecar logs, without retrying. 
+When an actor's method completes successfully, the runtime will continue to invoke the method at the specified timer or reminder schedule. However, if the method throws an exception, the runtime catches it and logs the error message in the Dapr sidecar logs, without retrying.
 
 To allow actors to recover from failures and retry after a crash or restart, you can persist an actor's state by configuring a state store, like Redis or Azure Cosmos DB. 
 
@@ -155,38 +151,6 @@ If an invocation of the method fails, the timer is not removed. Timers are only
 - The executions run out
 - You delete it explicitly
 
-## Reminder data serialization format
-
-Actor reminder data is serialized to JSON by default. Dapr v1.13 onwards supports a protobuf serialization format for internal reminders data for workflow via both the Placement and Scheduler services. Depending on throughput and size of the payload, this can result in significant performance improvements, giving developers a higher throughput and lower latency. 
-
-Another benefit is storing smaller data in the actor underlying database, which can result in cost optimizations when using some cloud databases. A restriction with using protobuf serialization is that the reminder data can no longer be queried. 
-
-{{% alert title="Note" color="primary" %}}
-Protobuf serialization will become the default format in Dapr 1.14
-{{% /alert %}}
-
-Reminder data saved in protobuf format cannot be read in Dapr 1.12.x and earlier versions. Its recommended to test this feature in Dapr v1.13 and verify that it works as expected with your database before taking this into production. 
-
-{{% alert title="Note" color="primary" %}}
-If you use protobuf serialization in Dapr v1.13 and need to downgrade to an earlier Dapr version, the reminder data will be incompatible with versions 1.12.x and earlier versions. **Once you save your reminders data in protobuf format, you cannot move it back to JSON format**.
-{{% /alert %}}
-
-### Enabling protobuf serialization on Kubernetes
-
-To use protobuf serialization for actor reminders on Kubernetes, use the following Helm value:
-
-```
---set dapr_placement.maxActorApiLevel=20
-```
-
-### Enabling protobuf serialization on self-hosted
-
-To use protobuf serialization for actor reminders on self-hosted, use the following `daprd` flag:
-
-```
---max-api-level=20
-```
-
 ## Managing reminders with the CLI
 
 Actor reminders are persisted in the Scheduler.