Merge branch 'v1.14' into filinto/high-priority-class-name

README.md

@@ -1,5 +1,7 @@
 # Dapr documentation
 
+[![GitHub License](https://img.shields.io/github/license/dapr/docs?style=flat&label=License&logo=github)](https://github.com/dapr/docs/blob/v1.13/LICENSE) [![GitHub issue custom search in repo](https://img.shields.io/github/issues-search/dapr/docs?query=type%3Aissue%20is%3Aopen%20label%3A%22good%20first%20issue%22&label=Good%20first%20issues&style=flat&logo=github)](https://github.com/dapr/docs/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) [![Discord](https://img.shields.io/discord/778680217417809931?label=Discord&style=flat&logo=discord)](http://bit.ly/dapr-discord) [![YouTube Channel Views](https://img.shields.io/youtube/channel/views/UCtpSQ9BLB_3EXdWAUQYwnRA?style=flat&label=YouTube%20views&logo=youtube)](https://youtube.com/@daprdev) [![X (formerly Twitter) Follow](https://img.shields.io/twitter/follow/daprdev?logo=x&style=flat)](https://twitter.com/daprdev)
+
 If you are looking to explore the Dapr documentation, please go to the documentation website:
 
 [**https://docs.dapr.io**](https://docs.dapr.io)

daprdocs/content/en/concepts/building-blocks-concept.md

@@ -21,12 +21,12 @@ Dapr provides the following building blocks:
 | Building Block | Endpoint | Description |
 |----------------|----------|-------------|
 | [**Service-to-service invocation**]({{< ref "service-invocation-overview.md" >}}) | `/v1.0/invoke` | Service invocation enables applications to communicate with each other through well-known endpoints in the form of http or gRPC messages. Dapr provides an endpoint that acts as a combination of a reverse proxy with built-in service discovery, while leveraging built-in distributed tracing and error handling.
-| [**State management**]({{< ref "state-management-overview.md" >}}) | `/v1.0/state` | Application state is anything an application wants to preserve beyond a single session. Dapr provides a key/value-based state and query APIs with pluggable state stores for persistence.
 | [**Publish and subscribe**]({{< ref "pubsub-overview.md" >}}) | `/v1.0/publish` `/v1.0/subscribe`|  Pub/Sub is a loosely coupled messaging pattern where senders (or publishers) publish messages to a topic, to which subscribers subscribe. Dapr supports the pub/sub pattern between applications.
+| [**Workflows**]({{< ref "workflow-overview.md" >}}) | `/v1.0-beta1/workflow` | The Workflow API enables you to define long running, persistent processes or data flows that span multiple microservices using Dapr workflows or workflow components. The Workflow API can be combined with other Dapr API building blocks. For example, a workflow can call another service with service invocation or retrieve secrets, providing flexibility and portability. 
+| [**State management**]({{< ref "state-management-overview.md" >}}) | `/v1.0/state` | Application state is anything an application wants to preserve beyond a single session. Dapr provides a key/value-based state and query APIs with pluggable state stores for persistence.
 | [**Bindings**]({{< ref "bindings-overview.md" >}}) | `/v1.0/bindings` | A binding provides a bi-directional connection to an external cloud/on-premise service or system. Dapr allows you to invoke the external service through the  Dapr binding API, and it allows your application to be triggered by events sent by the connected service.
 | [**Actors**]({{< ref "actors-overview.md" >}}) | `/v1.0/actors` |  An actor is an isolated, independent unit of compute and state with single-threaded execution. Dapr provides an actor implementation based on the virtual actor pattern which provides a single-threaded programming model and where actors are garbage collected when not in use.
 | [**Secrets**]({{< ref "secrets-overview.md" >}}) | `/v1.0/secrets` | Dapr provides a secrets building block API and integrates with secret stores such as public cloud stores, local stores and Kubernetes to store the secrets. Services can call the secrets API to retrieve secrets, for example to get a connection string to a database.
 | [**Configuration**]({{< ref "configuration-api-overview.md" >}}) | `/v1.0/configuration` | The Configuration API enables you to retrieve and subscribe to application configuration items for supported configuration stores. This enables an application to retrieve specific configuration information, for example, at start up or when configuration changes are made in the store. 
 | [**Distributed lock**]({{< ref "distributed-lock-api-overview.md" >}}) | `/v1.0-alpha1/lock` | The distributed lock API enables you to take a lock on a resource so that multiple instances of an application can access the resource without conflicts and provide consistency guarantees.  
-| [**Workflows**]({{< ref "workflow-overview.md" >}}) | `/v1.0-beta1/workflow` | The Workflow API enables you to define long running, persistent processes or data flows that span multiple microservices using Dapr workflows or workflow components. The Workflow API can be combined with other Dapr API building blocks. For example, a workflow can call another service with service invocation or retrieve secrets, providing flexibility and portability. 
 | [**Cryptography**]({{< ref "cryptography-overview.md" >}}) | `/v1.0-alpha1/crypto` | The Cryptography API enables you to perform cryptographic operations, such as encrypting and decrypting messages, without exposing keys to your application.

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

@@ -64,13 +64,6 @@ The component is unavailable for a short period of time during reload and reinit
 
 The following are the component types provided by Dapr:
 
-### State stores
-
-State store components are data stores (databases, files, memory) that store key-value pairs as part of the [state management]({{< ref "state-management-overview.md" >}}) building block.
-
-- [List of state stores]({{< ref supported-state-stores >}})
-- [State store implementations](https://github.com/dapr/components-contrib/tree/master/state)
-
 ### Name resolution
 
 Name resolution components are used with the [service invocation]({{< ref "service-invocation-overview.md" >}}) building block to integrate with the hosting environment and provide service-to-service discovery. For example, the Kubernetes name resolution component integrates with the Kubernetes DNS service, self-hosted uses mDNS and clusters of VMs can use the Consul name resolution component.
@@ -85,6 +78,20 @@ Pub/sub broker components are message brokers that can pass messages to/from ser
 - [List of pub/sub brokers]({{< ref supported-pubsub >}})
 - [Pub/sub broker implementations](https://github.com/dapr/components-contrib/tree/master/pubsub)
 
+### Workflows
+
+A [workflow]({{< ref workflow-overview.md >}}) is custom application logic that defines a reliable business process or data flow. Workflow components are workflow runtimes (or engines) that run the business logic written for that workflow and store their state into a state store.  
+
+<!--- [List of supported workflows]()
+- [Workflow implementations](https://github.com/dapr/components-contrib/tree/master/workflows)-->
+
+### State stores
+
+State store components are data stores (databases, files, memory) that store key-value pairs as part of the [state management]({{< ref "state-management-overview.md" >}}) building block.
+
+- [List of state stores]({{< ref supported-state-stores >}})
+- [State store implementations](https://github.com/dapr/components-contrib/tree/master/state)
+
 ### Bindings
 
 External resources can connect to Dapr in order to trigger a method on an application or be called from an application as part of the [bindings]({{< ref bindings-overview.md >}}) building block.
@@ -113,13 +120,6 @@ Lock components are used as a distributed lock to provide mutually exclusive acc
 - [List of supported locks]({{< ref supported-locks >}})
 - [Lock implementations](https://github.com/dapr/components-contrib/tree/master/lock)
 
-### Workflows
-
-A [workflow]({{< ref workflow-overview.md >}}) is custom application logic that defines a reliable business process or data flow. Workflow components are workflow runtimes (or engines) that run the business logic written for that workflow and store their state into a state store.  
-
-<!--- [List of supported workflows]()
-- [Workflow implementations](https://github.com/dapr/components-contrib/tree/master/workflows)-->
-
 ### Cryptography
 
 [Cryptography]({{< ref cryptography-overview.md >}}) components are used to perform crypographic operations, including encrypting and decrypting messages, without exposing keys to your application.

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

@@ -2,25 +2,29 @@
 type: docs
 title: "Dapr Placement control plane service overview"
 linkTitle: "Placement"
-description: "Overview of the Dapr placement service"
+description: "Overview of the Dapr Placement service"
 ---
 
-The Dapr Placement service is used to calculate and distribute distributed hash tables for the location of [Dapr actors]({{< ref actors >}}) running in [self-hosted mode]({{< ref self-hosted >}}) or on [Kubernetes]({{< ref kubernetes >}}). This hash table maps actor IDs to pods or processes so a Dapr application can communicate with the actor.Anytime a Dapr application activates a Dapr actor, the placement updates the hash tables with the latest actor locations.
+The Dapr Placement service is used to calculate and distribute distributed hash tables for the location of [Dapr actors]({{< ref actors >}}) running in [self-hosted mode]({{< ref self-hosted >}}) or on [Kubernetes]({{< ref kubernetes >}}). Grouped by namespace, the hash tables map actor types to pods or processes so a Dapr application can communicate with the actor. Anytime a Dapr application activates a Dapr actor, the Placement service updates the hash tables with the latest actor location.
 
 ## Self-hosted mode
 
-The placement service Docker container is started automatically as part of [`dapr init`]({{< ref self-hosted-with-docker.md >}}). It can also be run manually as a process if you are running in [slim-init mode]({{< ref self-hosted-no-docker.md >}}).
+The Placement service Docker container is started automatically as part of [`dapr init`]({{< ref self-hosted-with-docker.md >}}). It can also be run manually as a process if you are running in [slim-init mode]({{< ref self-hosted-no-docker.md >}}).
 
 ## 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. For more information on running Dapr on Kubernetes, visit the [Kubernetes hosting page]({{< ref kubernetes >}}).
 
 ## Placement tables
 
-There is an [HTTP API `/placement/state` for placement service]({{< ref placement_api.md >}}) that exposes placement table information. The API is exposed on the sidecar on the same port as the healthz. This is an unauthenticated endpoint, and is disabled by default. You need to set `DAPR_PLACEMENT_METADATA_ENABLED` environment or `metadata-enabled` command line args to true to enable it. If you are using helm you just need to set `dapr_placement.metadataEnabled` to true.
+There is an [HTTP API `/placement/state` for Placement service]({{< ref placement_api.md >}}) that exposes placement table information. The API is exposed on the sidecar on the same port as the healthz. This is an unauthenticated endpoint, and is disabled by default. You need to set `DAPR_PLACEMENT_METADATA_ENABLED` environment or `metadata-enabled` command line args to true to enable it. If you are using helm you just need to set `dapr_placement.metadataEnabled` to true.
+
+{{% alert title="Important" color="warning" %}}
+When deploying actors into different namespaces ({{< ref namespaced-actors.md >}}), it is recommended to disable the `metadata-enabled` if you want to prevent retrieving actors from all namespaces. The metadata endpoint is scoped to all namespaces.
+{{% /alert %}}
 
 ### Usecase:
-The placement table API can be used for retrieving the current placement table, which contains all the actors registered. This can be helpful for debugging and allows tools to extract and present information about actors.
+The placement table API can be used to retrieve the current placement table, which contains all the actors registered across all namespaces. This is helpful for debugging and allowing tools to extract and present information about actors.
 
 ### HTTP Request
 
@@ -61,26 +65,29 @@ updatedAt | timestamp | Timestamp of the actor registered/updated.
 
 ```json
 {
-	"hostList": [{
-			"name": "198.18.0.1:49347",
-			"appId": "actor1",
-			"actorTypes": ["testActorType1", "testActorType3"],
-			"updatedAt": 1690274322325260000
-		},
-		{
-			"name": "198.18.0.2:49347",
-			"appId": "actor2",
-			"actorTypes": ["testActorType2"],
-			"updatedAt": 1690274322325260000
-		},
-		{
-			"name": "198.18.0.3:49347",
-			"appId": "actor2",
-			"actorTypes": ["testActorType2"],
-			"updatedAt": 1690274322325260000
-		}
-	],
-	"tableVersion": 1
+    "hostList": [{
+            "name": "198.18.0.1:49347",
+            "namespace": "ns1",
+            "appId": "actor1",
+            "actorTypes": ["testActorType1", "testActorType3"],
+            "updatedAt": 1690274322325260000
+        },
+        {
+            "name": "198.18.0.2:49347",
+            "namespace": "ns2",
+            "appId": "actor2",
+            "actorTypes": ["testActorType2"],
+            "updatedAt": 1690274322325260000
+        },
+        {
+            "name": "198.18.0.3:49347",
+            "namespace": "ns2",
+            "appId": "actor2",
+            "actorTypes": ["testActorType2"],
+            "updatedAt": 1690274322325260000
+        }
+    ],
+    "tableVersion": 1
 }
 ```
 

daprdocs/content/en/concepts/faq/_index.md

@@ -0,0 +1,7 @@
+---
+type: docs
+title: "Frequently asked questions and answers"
+linkTitle: "FAQs"
+weight: 1100
+description: "Learn more about Dapr concepts through frequently asked questions"
+---

daprdocs/content/en/concepts/faq.md → daprdocs/content/en/concepts/faq/faq.md

@@ -1,8 +1,8 @@
 ---
 type: docs
-title: "Frequently asked questions and answers"
-linkTitle: "FAQs"
-weight: 1000
+title: "General Dapr questions and answers"
+linkTitle: "General questions"
+weight: 100
 description: "Common questions asked about Dapr"
 ---
 

daprdocs/content/en/concepts/service-mesh.md → daprdocs/content/en/concepts/faq/service-mesh.md

@@ -2,7 +2,7 @@
 type: docs
 title: "Dapr and service meshes"
 linkTitle: "Service meshes"
-weight: 900
+weight: 200
 description: >
   How Dapr compares to and works with service meshes
 ---

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

@@ -0,0 +1,45 @@
+---
+type: docs
+title: "Isolation"
+linkTitle: "Isolation"
+weight: 700
+description: How Dapr provides namespacing and isolation
+---
+
+Dapr namespacing provides isolation and multi-tenancy across many capabilities, giving greater security. Typically applications and components are deployed to namespaces to provide isolation in a given environment, such as Kubernetes. 
+
+Dapr supports namespacing in service invocation calls between applications, when accessing components, sending pub/sub messages in consumer groups, and with actors type deployments as examples. Namespacing isolation is supported in both self-hosted and Kubernetes modes. 
+
+To get started, create and configure your namespace.
+
+{{< tabs "Self-Hosted" "Kubernetes">}}
+
+{{% codetab %}}
+
+In self-hosted mode, specify the namespace for a Dapr instance by setting the `NAMESPACE` environment variable.
+
+{{% /codetab %}}
+
+{{% codetab %}}
+
+On Kubernetes, create and configure the namespace:
+
+```bash
+kubectl create namespace namespaceA
+kubectl config set-context --current --namespace=namespaceA
+```
+
+Then deploy your applications into this namespace.
+
+{{% /codetab %}}
+
+{{< /tabs >}}
+
+Learn how to use namespacing throughout Dapr:
+
+- [Service Invocation namespaces]({{< ref service-invocation-namespaces.md >}})
+- [How to: Set up pub/sub namespace consumer groups]({{< ref howto-namespace.md >}})
+- Components:
+  - [How to: Configure pub/sub components with multiple namespaces]({{< ref pubsub-namespaces.md >}})
+  - [Scope components to one or more applications]({{< ref component-scopes.md >}})
+- [Namespaced actors]({{< ref namespaced-actors.md >}})

daprdocs/content/en/concepts/overview.md

@@ -45,14 +45,14 @@ Each of these building block APIs is independent, meaning that you can use any n
 | Building Block | Description |
 |----------------|-------------|
 | [**Service-to-service invocation**]({{< ref "service-invocation-overview.md" >}})  | Resilient service-to-service invocation enables method calls, including retries, on remote services, wherever they are located in the supported hosting environment.
-|  [**State management**]({{< ref "state-management-overview.md" >}}) | With state management for storing and querying key/value pairs, long-running, highly available, stateful services can be easily written alongside stateless services in your application. The state store is pluggable and examples include AWS DynamoDB, Azure Cosmos DB, Azure SQL Server, GCP Firebase, PostgreSQL or Redis, among others.
 | [**Publish and subscribe**]({{< ref "pubsub-overview.md" >}}) | Publishing events and subscribing to topics between services enables event-driven architectures to simplify horizontal scalability and make them resilient to failure. Dapr provides at-least-once message delivery guarantee, message TTL, consumer groups and other advance features.
+| [**Workflows**]({{< ref "workflow-overview.md" >}}) | The workflow API can be combined with other Dapr building blocks to define long running, persistent processes or data flows that span multiple microservices using Dapr workflows or workflow components. 
+| [**State management**]({{< ref "state-management-overview.md" >}}) | With state management for storing and querying key/value pairs, long-running, highly available, stateful services can be easily written alongside stateless services in your application. The state store is pluggable and examples include AWS DynamoDB, Azure Cosmos DB, Azure SQL Server, GCP Firebase, PostgreSQL or Redis, among others.
 | [**Resource bindings**]({{< ref "bindings-overview.md" >}}) | Resource bindings with triggers builds further on event-driven architectures for scale and resiliency by receiving and sending events to and from any external source such as databases, queues, file systems, etc.
 | [**Actors**]({{< ref "actors-overview.md" >}}) | A pattern for stateful and stateless objects that makes concurrency simple, with method and state encapsulation. Dapr provides many capabilities in its actor runtime, including concurrency, state, and life-cycle management for actor activation/deactivation, and timers and reminders to wake up actors.
 | [**Secrets**]({{< ref "secrets-overview.md" >}}) | The secrets management API integrates with public cloud and local secret stores to retrieve the secrets for use in application code.
 | [**Configuration**]({{< ref "configuration-api-overview.md" >}})  | The configuration API enables you to retrieve and subscribe to application configuration items from configuration stores. 
 | [**Distributed lock**]({{< ref "distributed-lock-api-overview.md" >}})  | The distributed lock API enables your application to acquire a lock for any resource that gives it exclusive access until either the lock is released by the application, or a lease timeout occurs. 
-| [**Workflows**]({{< ref "workflow-overview.md" >}}) | The workflow API can be combined with other Dapr building blocks to define long running, persistent processes or data flows that span multiple microservices using Dapr workflows or workflow components. 
 | [**Cryptography**]({{< ref "cryptography-overview.md" >}}) | The cryptography API provides an abstraction layer on top of security infrastructure such as key vaults. It contains APIs that allow you to perform cryptographic operations, such as encrypting and decrypting messages, without exposing keys to your applications.
 
 ### Cross-cutting APIs