Upmerge from 1.15 into 1.16

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

@@ -93,6 +93,22 @@ updatedAt | timestamp | Timestamp of the actor registered/updated.
 }
 ```
 
+## Disabling the Placement service
+
+
+The Placement service can be disabled with the following setting:
+
+
+```
+global.actors.enabled=false
+```
+
+The Placement service is not deployed with this setting in Kubernetes mode. This not only disables actor deployment, but also disables workflows, given that workflows use actors. This setting only applies in Kubernetes mode, however initializing Dapr with `--slim` excludes the Placement service from being deployed in self-hosted mode. 
+
+
+For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page](https://docs.dapr.io/operations/hosting/kubernetes/).
+
+
 ## Related links
 
-[Learn more about the Placement API.]({{% ref placement_api %}})
+[Learn more about the Placement API.]({{% ref placement_api %}})

daprdocs/content/en/developing-applications/building-blocks/bindings/howto-bindings.md

@@ -112,8 +112,6 @@ The code examples below leverage Dapr SDKs to invoke the output bindings endpoin
 
 Here's an example of using a console app with top-level statements in .NET 6+:
 
-Here's an example of using a console app with top-level statements in .NET 6+:
-
 ```csharp
 using System.Text;
 using System.Threading.Tasks;

daprdocs/content/en/developing-applications/building-blocks/bindings/howto-triggers.md

@@ -121,8 +121,6 @@ Below are code examples that leverage Dapr SDKs to demonstrate an input binding.
 
 The following example demonstrates how to configure an input binding using ASP.NET Core controllers.
 
-The following example demonstrates how to configure an input binding using ASP.NET Core controllers.
-
 ```csharp
 using System.Collections.Generic;
 using System.Threading.Tasks;
@@ -152,6 +150,15 @@ app.MapPost("checkout", ([FromBody] int orderId) =>
 });
 ```
 
+The following example demonstrates how to configure the same input binding using a minimal API approach:
+```csharp
+app.MapPost("checkout", ([FromBody] int orderId) =>
+{
+    Console.WriteLine($"Received Message: {orderId}");
+    return $"CID{orderId}"
+});
+```
+
 {{% /tab %}}
 
 {{% tab "Java" %}}

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

@@ -59,7 +59,7 @@ Want to put the Dapr conversation API to the test? Walk through the following qu
 
 | Quickstart/tutorial | Description |
 | ------------------- | ----------- |
-| [Conversation quickstart]({{% ref conversation-quickstart %}}) | Learn how to  interact with Large Language Models (LLMs) using the conversation API. |
+| [Conversation quickstart]({{% ref conversation-quickstart %}}) | Learn how to interact with Large Language Models (LLMs) using the conversation API. |
 
 ### Start using the conversation API directly in your app
 

daprdocs/content/en/developing-applications/building-blocks/pubsub/pubsub-raw.md

@@ -111,7 +111,7 @@ Dapr apps can subscribe to raw messages from pub/sub topics, even if they weren
 
 ### Programmatically subscribe to raw events
 
-When subscribing programmatically, add the additional metadata entry for `rawPayload` to allow the subscriber to receive a message that is not wrapped by a CloudEvent. For .NET, this metadata entry is called `rawPayload`. 
+When subscribing programmatically, add the additional metadata entry for `rawPayload` to allow the subscriber to receive a message that is not wrapped by a CloudEvent. For .NET, this metadata entry is called `isRawPayload`. 
 
 When using raw payloads the message is always base64 encoded with content type `application/octet-stream`.
 

daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/authenticating-azure.md

@@ -9,38 +9,41 @@ aliases:
 weight: 10000
 ---
 
-Most Azure components for Dapr support authenticating with Microsoft Entra ID. Thanks to this:
-
-- Administrators can leverage all the benefits of fine-tuned permissions with Azure Role-Based Access Control (RBAC).
-- Applications running on Azure services such as Azure Container Apps, Azure Kubernetes Service, Azure VMs, or any other Azure platform services can leverage [Managed Identities (MI)](https://learn.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) and [Workload Identity](https://learn.microsoft.com/azure/aks/workload-identity-overview). These offer the ability to authenticate your applications without having to manage sensitive credentials.
-
 ## About authentication with Microsoft Entra ID
 
-Microsoft Entra ID is Azure's identity and access management (IAM) solution, which is used to authenticate and authorize users and services.
+Microsoft Entra ID is Azure's identity and access management (IAM) solution, which is used to authenticate and authorize users and services. It's built on top of open standards such OAuth 2.0, which allows services (applications) to obtain access tokens to make requests to Azure services, including Azure Storage, Azure Service Bus, Azure Key Vault, Azure Cosmos DB, Azure Database for Postgres, Azure SQL, etc.
 
-Microsoft Entra ID is built on top of open standards such OAuth 2.0, which allows services (applications) to obtain access tokens to make requests to Azure services, including Azure Storage, Azure Service Bus, Azure Key Vault, Azure Cosmos DB, Azure Database for Postgres, Azure SQL, etc. 
+## Options to authenticate
 
-> In Azure terminology, an application is also called a "Service Principal".
+Applications can authenticate with Microsoft Entra ID and obtain an access token to make requests to Azure services through several methods:
 
-Some Azure components offer alternative authentication methods, such as systems based on "shared keys" or "access tokens". Although these are valid and supported by Dapr, you should authenticate your Dapr components using Microsoft Entra ID whenever possible to take advantage of many benefits, including:
+ - [Workload identity federation]({{< ref howto-wif.md >}}) - The recommended way to configure your Microsoft Entra ID tenant to trust an external identity provider.  This includes service accounts from Kubernetes or AKS clusters. [Learn more about workload identity federation](https://learn.microsoft.com/entra/workload-id/workload-identities-overview).
+ - [System and user assigned managed identities]({{< ref howto-mi.md >}}) - Less granular than workload identity federation, but retains some of the benefits.  [Learn more about system and user assigned managed identities](https://learn.microsoft.com/azure/aks/use-managed-identity).
+ - [Client ID and secret]({{ < ref howto-aad.md >}}) - Not recommended as it requires you to maintian and associate credentials at the application level.
+ - Pod Identities - [Deprecated approach for authenticating applications running on Kubernetes pods](https://learn.microsoft.com/azure/aks/use-azure-ad-pod-identity) at a pod level.  This should no longer be used.
 
-- [Managed Identities and Workload Identity](#managed-identities-and-workload-identity)
-- [Role-Based Access Control](#role-based-access-control)
-- [Auditing](#auditing)
-- [(Optional) Authentication using certificates](#optional-authentication-using-certificates)
+If you are just getting started, it is recommended to use workload identity federation.
+
+## Managed identities and workload identity federation
 
-### Managed Identities and Workload Identity
+When your application is running on a supported Azure service (such as Azure VMs, Azure Container Apps, Azure Web Apps, etc), an identity for your application can be assigned at the infrastructure level.
 
-With Managed Identities (MI), your application can authenticate with Microsoft Entra ID and obtain an access token to make requests to Azure services. When your application is running on a supported Azure service (such as Azure VMs, Azure Container Apps, Azure Web Apps, etc), an identity for your application can be assigned at the infrastructure level.
+This is done through [system or user assigned managed identities]({{< ref howto-mi.md >}}), or [workload identity federation]({{< ref howto-wif.md >}}).
 
-Once using MI, your code doesn't have to deal with credentials, which:
+Once using managed identities, your code doesn't have to deal with credentials, which:
 
 - Removes the challenge of managing credentials safely
 - Allows greater separation of concerns between development and operations teams
 - Reduces the number of people with access to credentials
 - Simplifies operational aspects–especially when multiple environments are used
 
-Applications running on Azure Kubernetes Service can similarly leverage [Workload Identity](https://learn.microsoft.com/azure/aks/workload-identity-overview) to automatically provide an identity to individual pods.
+While some Dapr Azure components offer alternative authentication methods, such as systems based on "shared keys" or "access tokens", you should always try to authenticate your Dapr components using Microsoft Entra ID whenever possible. This offers many benefits, including:
+
+- [Role-Based Access Control](#role-based-access-control)
+- [Auditing](#auditing)
+- [(Optional) Authentication using certificates](#optional-authentication-using-certificates)
+
+It's recommended that applications running on Azure Kubernetes Service leverage [workload identity federation](https://learn.microsoft.com/entra/workload-id/workload-identity-federation) to automatically provide an identity to individual pods.
 
 ### Role-Based Access Control
 

daprdocs/content/en/developing-applications/integrations/Azure/azure-authentication/howto-wif.md

@@ -0,0 +1,111 @@
+---
+type: docs
+title: "How to: Use workload identity federation"
+linkTitle: "How to: Use workload identity federation"
+weight: 20000
+description: "Learn how to configure Dapr to use workload identity federation on Azure."
+---
+
+This guide will help you configure your Kubernetes cluster to run Dapr with Azure workload identity federation.
+
+## What is it?
+
+[Workload identity federation](https://learn.microsoft.com/entra/workload-id/workload-identities-overview) 
+is a way for your applications to authenticate to Azure without having to store or manage credentials as part of 
+your releases.
+
+By using workload identity federation, any Dapr components running on Kubernetes and AKS that target Azure can authenticate transparently
+with no extra configuration.
+
+## Guide 
+
+We'll show how to configure an Azure Key Vault resource against your AKS cluster. You can adapt this guide for different 
+Dapr Azure components by substituting component definitions as necessary.
+
+For this How To, we'll use this [Dapr AKS secrets sample app](https://github.com/dapr/samples/dapr-aks-workload-identity-federation).
+
+### Prerequisites
+
+ - AKS cluster with workload identity enabled
+ - Microsoft Entra ID tenant
+
+### 1 - Enable workload identity federation
+
+Follow [the Azure documentation for enabling workload identity federation on your AKS cluster](https://learn.microsoft.com/azure/aks/workload-identity-deploy-cluster#deploy-your-application4).
+
+The HowTo walks through configuring your Azure Entra ID tenant to trust an identity that originates from your AKS cluster issuer.
+It also guides you in setting up a [Kubernetes service account](https://kubernetes.io/docs/concepts/security/service-accounts/) which 
+is associated with an Azure managed identity you create.
+
+Once completed, return here to continue with step 2.
+
+### 2 - Add a secret to Azure Key Vault
+
+In the Azure Key Vault you created and add a secret called `dapr` with the value of `Hello Dapr!`.
+
+### 3 - Configure the Azure Key Vault dapr component
+
+By this point, you should have a Kubernetes service account with a name similar to `workload-identity-sa0a1b2c`.
+
+Apply the following to your Kubernetes cluster, remembering to update `your-key-vault` with the name of your key vault:
+
+```yaml
+---
+apiVersion: dapr.io/v1alpha1
+kind: Component
+metadata:
+  name: demo-secret-store # Be sure not to change this, as our app will be looking for it.
+spec:
+  type: secretstores.azure.keyvault
+  version: v1
+  metadata:
+  - name: vaultName
+    value: your-key-vault # Replace
+```
+
+You'll notice that we have not provided any details specific to authentication in the component definition.  This is intentional, as Dapr is able to leverage the Kubernetes service account to transparently authenticate to Azure.
+
+### 4 - Deploy the test application
+
+Go to the  [workload identity federation sample application](https://github.com/dapr/samples/dapr-aks-workload-identity-federation) and prepare a build of the image.
+
+Make sure the image is pushed up to a registry that your AKS cluster has visibility and permission to pull from.
+
+Next, create a deployment for our sample AKS secrets app container along with a Dapr sidecar.
+
+Remember to update `dapr-wif-k8s-service-account` with your service account name and `dapraksworkloadidentityfederation` with an image your cluster can resolve:
+
+
+```yaml
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: aks-dapr-wif-secrets
+  labels:
+    app: aks-dapr-wif-secrets
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: aks-dapr-wif-secrets
+  template:
+    metadata:
+      labels:
+        app: aks-dapr-wif-secrets
+        azure.workload.identity/use: "true" # Important
+      annotations:
+        dapr.io/enabled: "true" # Enable Dapr
+        dapr.io/app-id: "aks-dapr-wif-secrets"
+    spec:
+      serviceAccountName: dapr-wif-k8s-service-account # Remember to replace
+      containers:
+        - name: workload-id-demo
+          image: dapraksworkloadidentityfederation # Remember to replace
+          imagePullPolicy: Always
+```
+Once the application is up and running, it should output the following:
+
+```
+Fetched Secret: Hello dapr!
+```

daprdocs/content/en/developing-applications/local-development/sdk-serialization.md

@@ -81,6 +81,8 @@ Content-Length: 12
     client.saveState("MyStateStore", "MyKey", "My Message").block();
 ```
 
+In this example, `My Message` is saved. It is not quoted because Dapr's API internally parse the JSON request object before saving it.
+
 {{% /tab %}}
 
 {{< /tabpane >}}
@@ -100,9 +102,7 @@ serving it.
     await client.PublishEventAsync("MyPubSubName", "TopicName", "My Message");
 ```
 
-The event is published and the content is serialized to `byte[]` and sent to Dapr sidecar. The subscriber receives it 
-as a [CloudEvent](https://github.com/cloudevents/spec). Cloud event defines `data` as string. The Dapr SDK also provides a built-in deserializer 
-for the `CloudEvent` object. 
+The event is published and the content is serialized to `byte[]` and sent to Dapr sidecar. The subscriber receives it as a [CloudEvent](https://github.com/cloudevents/spec). Cloud event defines `data` as string. The Dapr SDK also provides a built-in deserializer for the `CloudEvent` object. 
 
 ```csharp
 public async Task<IActionResult> HandleMessage(string message) 

daprdocs/content/en/operations/configuration/secret-scope.md

@@ -7,7 +7,6 @@ description: "Define secret scopes by augmenting the existing configuration reso
 description: "Define secret scopes by augmenting the existing configuration resource with restrictive permissions."
 ---
 
-In addition to [scoping which applications can access a given component]({{% ref "component-scopes.md"%}}), you can also scope a named secret store component to one or more secrets for an application. By defining `allowedSecrets` and/or `deniedSecrets` lists, you restrict applications to access only specific secrets.
 In addition to [scoping which applications can access a given component]({{% ref "component-scopes.md"%}}), you can also scope a named secret store component to one or more secrets for an application. By defining `allowedSecrets` and/or `deniedSecrets` lists, you restrict applications to access only specific secrets.
 
 For more information about configuring a Configuration resource:

daprdocs/content/en/operations/hosting/kubernetes/kubernetes-persisting-scheduler.md

@@ -85,6 +85,14 @@ kubectl delete pvc -n dapr-system dapr-scheduler-data-dir-dapr-scheduler-server-
 Persistent Volume Claims are not deleted automatically with an [uninstall]({{< ref dapr-uninstall.md >}}). This is a deliberate safety measure to prevent accidental data loss.
 {{% /alert %}}
 
+{{% alert title="Note" color="primary" %}}
+For storage providers that do NOT support dynamic volume expansion: If Dapr has ever been installed on the cluster before, the Scheduler's Persistent Volume Claims must be manually uninstalled in order for new ones with increased storage size to be created.
+```bash
+kubectl delete pvc -n dapr-system dapr-scheduler-data-dir-dapr-scheduler-server-0 dapr-scheduler-data-dir-dapr-scheduler-server-1 dapr-scheduler-data-dir-dapr-scheduler-server-2
+```
+Persistent Volume Claims are not deleted automatically with an [uninstall]({{< ref dapr-uninstall.md >}}). This is a deliberate safety measure to prevent accidental data loss.
+{{% /alert %}}
+
 #### Increase existing Scheduler Storage Size
 
 {{% alert title="Warning" color="warning" %}}