Merge branch 'hugo-docs' of https://github.com/dapr/docs into hugo-docs

README.md

@@ -35,3 +35,6 @@ The [daprdocs](./daprdocs) directory contains the hugo project, markdown files,
 
 ## Authoring guide
 Read the [authoring guide](./authoring-guide.md) for info on how to write docs and be consistent.
+
+## Code of Conduct
+Please refer to our [Dapr community code of conduct](https://github.com/dapr/community/blob/master/CODE-OF-CONDUCT.md)

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

@@ -20,10 +20,10 @@ The following are the building blocks provided by Dapr:
 
 | 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 "service-invocation-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 API with pluggable state stores for persistence.
-| [**Publish and Subscribe**]({{<ref "service-invocation-overview.md">}}) | `/v1.0/publish` `/v1.0/subscribe`|  Pub/Sub is a loosely coupled messaging pattern where senders (or publishers) publishes messages to a topic, to which subscribers subscribe. Dapr supports the pub/sub pattern between applications.
-| [**Resource Bindings**]({{<ref "service-invocation-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 "service-invocation-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. See * [Actor Overview]({{< ref actors >}})
-| [**Observability**]({{<ref "service-invocation-overview.md">}}) | `N/A` |  Dapr system components and runtime emit metrics, logs, and traces to debug, operate and monitor Dapr system services, components and user applications.
-| [**Secrets**]({{<ref "service-invocation-overview.md">}}) | `/v1.0/secrets` | Dapr offers a secrets building block API and integrates with secret stores such as Azure Key Vault and Kubernetes to store the secrets. Service code can call the secrets API to retrieve secrets out of the Dapr supported secret stores.
+| [**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 API 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) publishes messages to a topic, to which subscribers subscribe. Dapr supports the pub/sub pattern between applications.
+| [**Resource 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. See * [Actor Overview](./actors#understanding-actors)
+| [**Observability**]({{<ref "observability-concept.md">}}) | `N/A` |  Dapr system components and runtime emit metrics, logs, and traces to debug, operate and monitor Dapr system services, components and user applications.
+| [**Secrets**]({{<ref "secrets-overview.md">}}) | `/v1.0/secrets` | Dapr offers a secrets building block API and integrates with secret stores such as Azure Key Vault and Kubernetes to store the secrets. Service code can call the secrets API to retrieve secrets out of the Dapr supported secret stores.

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

@@ -8,7 +8,7 @@ description: "Modular functionality used by building blocks and applications"
 
 Dapr uses a modular design where functionality is delivered as a component. Each component has an interface definition.  All of the components are pluggable so that you can swap out one component with the same interface for another. The [components contrib repo](https://github.com/dapr/components-contrib) is where you can contribute implementations for the component interfaces and extends Dapr's capabilities.
   
- A building block can use any combination of components. For example the [actors]({{<ref "service-invocation-overview.md">}}) building block and the [state management]({{<ref "service-invocation-overview.md">}}) building block both use [state components](https://github.com/dapr/components-contrib/tree/master/state).  As another example, the [pub/sub]({{<ref "service-invocation-overview.md">}}) building block uses [pub/sub](https://github.com/dapr/components-contrib/tree/master/pubsub) components.
+ A building block can use any combination of components. For example the [actors]({{<ref "actors-overview.md">}}) building block and the [state management]({{<ref "state-management-overview.md">}}) building block both use [state components](https://github.com/dapr/components-contrib/tree/master/state).  As another example, the [Pub/Sub]({{<ref "pubsub-overview.md">}}) building block uses [Pub/Sub components](https://github.com/dapr/components-contrib/tree/master/pubsub).
 
  You can get a list of current components available in the current hosting environment using the `dapr components` CLI command.
 
@@ -23,10 +23,10 @@ Dapr uses a modular design where functionality is delivered as a component. Each
 * [Tracing exporters](https://github.com/dapr/components-contrib/tree/master/exporters)
 
 ### Service invocation and service discovery components
-Service discovery components are used with the [Service Invocation]({{< ref service-invocation >}}) building block to integrate with the hosting environment to provide service-to-service discovery. For example, the Kubernetes service discovery component integrates with the kubernetes DNS service and self hosted uses mDNS.
+Service discovery components are used with the [service invocation]({{<ref "service-invocation-overview.md">}}) building block to integrate with the hosting environment to provide service-to-service discovery. For example, the Kubernetes service discovery component integrates with the Kubernetes DNS service and self hosted uses mDNS.
 
 ### Service invocation and middleware components  
-Dapr allows custom [**middleware**]({{< ref middleware-concept.md >}}) to be plugged into the request processing pipeline. Middleware can perform additional actions on a request, such as authentication, encryption and message transformation before the request is routed to the user code, or before the request is returned to the client. The middleware components are used with the [Service Invocation]({{< ref service-invocation >}}) building block.
+Dapr allows custom [middleware]({{<ref "middleware-concept.md">}})  to be plugged into the request processing pipeline. Middleware can perform additional actions on a request, such as authentication, encryption and message transformation before the request is routed to the user code, or before the request is returned to the client. The middleware components are used with the [service invocation]({{<ref "service-invocation-overview.md">}}) building block.
 
 ### Secret store components
-In Dapr, a [**secret**]({{< ref secrets >}}) is any piece of private information that you want to guard against unwanted users. Secretstores, used to store secrets, are Dapr components and can be used by any of the building blocks.
+In Dapr, a [secret]({{<ref "secrets-overview.md">}}) is any piece of private information that you want to guard against unwanted users. Secrets stores, used to store secrets, are Dapr components and can be used by any of the building blocks.

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

@@ -9,4 +9,4 @@ description: "Change the behavior of Dapr sidecars or globally on Dapr system se
 Dapr configurations are settings that enable you to change the behavior of individual Dapr application sidecars or globally on the system services in the Dapr control plane.
 An example of a per Dapr application sidecar setting is configuring trace settings. An example of a Dapr control plane setting is mutual TLS which is a global setting on the Sentry system service.
 
-Read [this page]({{< ref "configuration-overview.md" >}}) for a list of all configuration options.
+Read [this page]({{<ref "configuration-overview.md">}}) for a list of all configuration options.

daprdocs/content/en/concepts/faq.md

@@ -16,7 +16,9 @@ Dapr can be used alongside any service mesh such as Istio and Linkerd. A service
 
 That is where Dapr comes in. Dapr is a language agnostic programming model built on http and gRPC that provides distributed system building blocks via open APIs for asynchronous pub-sub, stateful services, service discovery and invocation, actors and distributed tracing. Dapr introduces new functionality to an app’s runtime. Both service meshes and Dapr run as side-car services to your application, one giving network features and the other distributed application capabilities.
 
-Watch this [video](https://www.youtube.com/watch?v=xxU68ewRmz8&feature=youtu.be&t=140) on how Dapr and service meshes work together.
+Watch this video on how Dapr and service meshes work together:
+
+<iframe width="560" height="315" src="https://www.youtube.com/embed/xxU68ewRmz8?start=141" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
 ### Understanding how Dapr interoperates with the service mesh interface (SMI)
 
@@ -24,19 +26,21 @@ SMI is an abstraction layer that provides a common API surface across different
 
 ### Differences between Dapr, Istio and Linkerd
 
-Read [How does Dapr work with service meshes?](https://github.com/dapr/dapr/wiki/FAQ#how-does-dapr-work-with-service-meshes) Istio is an open source service mesh implementation that focuses on Layer7 routing, traffic flow management and mTLS authentication between services. Istio uses a sidecar to intercept traffic going into and out of a container and enforces a set of network policies on them.
+Read [how does Dapr work with service meshes?](https://github.com/dapr/dapr/wiki/FAQ#how-does-dapr-work-with-service-meshes) Istio is an open source service mesh implementation that focuses on Layer7 routing, traffic flow management and mTLS authentication between services. Istio uses a sidecar to intercept traffic going into and out of a container and enforces a set of network policies on them.
 
 Istio is not a programming model and does not focus on application level features such as state management, pub-sub, bindings etc. That is where Dapr comes in.
 
 ## Performance Benchmarks
-The Dapr project is focused on performance due to the inherent discussion of Dapr being a sidecar to your application. This [performance benchmark video](https://youtu.be/4kV3SHs1j2k?t=783) discusses and demos the work that has been done so far. The performance benchmark data is planned to be published on a regular basis. You can also run the perf tests in your own environment to get perf numbers. 
+The Dapr project is focused on performance due to the inherent discussion of Dapr being a sidecar to your application. The performance benchmark data is planned to be published on a regular basis. You can also run the perf tests in your own environment to get perf numbers. This performance benchmark video discusses and demos the work that has been done so far. 
+
+<iframe width="560" height="315" src="https://www.youtube.com/embed/4kV3SHs1j2k?start=790" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
 ## Actors
 
 ### What is the relationship between Dapr, Orleans and Service Fabric Reliable Actors?
 
 The actors in Dapr are based on the same virtual actor concept that [Orleans](https://www.microsoft.com/research/project/orleans-virtual-actors/) started, meaning that they are activated when called and deactivated after a period of time. If you are familiar with Orleans, Dapr C# actors will be familiar. Dapr C# actors are based on [Service Fabric Reliable Actors](https://docs.microsoft.com/azure/service-fabric/service-fabric-reliable-actors-introduction) (which also came from Orleans) and enable you to take Reliable Actors in Service Fabric and migrate them to other hosting platforms such as Kubernetes or other on-premise environments.
-Also Dapr is about more than just actors. It provides you with a set of best practice building blocks to build into any microservices application. See [Dapr overview](https://github.com/dapr/docs/blob/master/overview/README.md).
+Also Dapr is about more than just actors. It provides you with a set of best practice building blocks to build into any microservices application. See [Dapr overview]({{<ref "overview.md">}}).
 
 ### Differences between Dapr from an actor framework
 

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

@@ -8,7 +8,7 @@ description: "Custom processing pipelines of chained middleware components"
 
 Dapr allows custom processing pipelines to be defined by chaining a series of middleware components. A request goes through all defined middleware components before it's routed to user code, and then goes through the defined middleware, in reverse order, before it's returned to the client, as shown in the following diagram.
 
-<img src="/images/middleware.png" width=800>
+<img src="/images/middleware.png" width=400>
 
 ## Customize processing pipeline
 
@@ -58,9 +58,9 @@ func GetHandler(metadata Metadata) fasthttp.RequestHandler {
 ```
 
 ## Adding new middleware components
-Your middleware component can be contributed to the https://github.com/dapr/components-contrib repository, under the */middleware* folder. 
+Your middleware component can be contributed to the [components-contrib repository](https://github.com/dapr/components-contrib/tree/master/middleware). 
 
-Then submit another pull request against the https://github.com/dapr/dapr repository to register the new middleware type. You'll need to modify the **Load()** method under https://github.com/dapr/dapr/blob/master/pkg/components/middleware/http/registry.go to register your middleware using the **Register** method.
+Then submit another pull request against the [Dapr runtime repository](https://github.com/dapr/dapr) to register the new middleware type. You'll need to modify the **Load()** method in [registry.go]( https://github.com/dapr/dapr/blob/master/pkg/components/middleware/http/registry.go) to register your middleware using the **Register** method.
 
 ## Next steps
 * [How-To: Configure API authorization with OAuth({{< ref oauth.md >}})

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

@@ -11,16 +11,18 @@ Observability is a term from control theory. Observability means you can answer
 
 The observability capabilities enable users to monitor the Dapr system services, their interaction with user applications and understand how these monitored services behave. The observability capabilities are divided into the following areas;
 
-- **[Distributed tracing]({{< ref tracing.md >}})**: is used to profile and monitor Dapr system services and user apps. Distributed tracing helps pinpoint where failures occur and what causes poor performance. Distributed tracing is particularly well-suited to debugging and monitoring distributed software architectures, such as microservices.
+* **[Distributed tracing]({{<ref "tracing.md">}})**: is used to profile and monitor Dapr system services and user apps. Distributed tracing helps pinpoint where failures occur and what causes poor performance. Distributed tracing is particularly well-suited to debugging and monitoring distributed software architectures, such as microservices.
 
     You can use distributed tracing to help debug and optimize application code. Distributed tracing contains trace spans between the Dapr runtime, Dapr system services, and user apps across process, nodes, network, and security boundaries. It provides a detailed understanding of service invocations (call flows) and service dependencies.
 
-    Dapr uses [W3C distributed tracing]({{< ref w3c-tracing >}})
+    Dapr uses [W3C tracing context for distributed tracing]({{<ref w3c-tracing>}})
 
     It is generally recommended to run Dapr in production with tracing.
-- **[Metrics]({{< ref metrics.md >}})**: are the series of measured values and counts that are collected and stored over time. Dapr metrics provide monitoring and understanding of the behavior of Dapr system services and user apps. For example, the service metrics between Dapr sidecars and user apps show call latency, traffic failures, error rates of requests etc. Dapr system services metrics show side car injection failures, health of the system services including CPU usage, number of actor placement made etc.  
-- **[Logs]({{< ref logs.md >}})**: are records of events that occur and can be used to determine failures or another status. Logs events contain warning, error, info, and debug messages produced by Dapr system services. Each log event includes metadata such as message type, hostname, component name, App ID, ip address, etc.
-- **[Health]({{< ref health_api.md>}})**: Dapr provides a way for a hosting platform to determine it's health using an HTTP endpoint. With this endpoint, the Dapr process, or sidecar, can be probed to determine its readiness and liveness and action taken accordingly.
+* **[Metrics]({{<ref "metrics.md">}})**: are the series of measured values and counts that are collected and stored over time. Dapr metrics provide monitoring and understanding of the behavior of Dapr system services and user apps. For example, the service metrics between Dapr sidecars and user apps show call latency, traffic failures, error rates of requests etc. Dapr system services metrics show side car injection failures, health of the system services including CPU usage, number of actor placement made etc.  
+
+* **[Logs]({{<ref "logs.md">}})**: are records of events that occur and can be used to determine failures or another status. Logs events contain warning, error, info, and debug messages produced by Dapr system services. Each log event includes metadata such as message type, hostname, component name, App ID, ip address, etc.
+
+* **[Health]({{<ref "sidecar-health.md">}})**: Dapr provides a way for a hosting platform to determine its health using an HTTP endpoint. With this endpoint, the Dapr process, or sidecar, can be probed to determine its readiness and liveness and action taken accordingly.
 
 ## Open Telemetry
 Dapr integrates with [OpenTelemetry](https://opentelemetry.io/) for tracing, metrics and logs. With OpenTelemetry, you can configure various exporters for tracing and metrics based on your environment, whether it is running in the cloud or on-premises.

daprdocs/content/en/concepts/overview.md

@@ -31,13 +31,13 @@ Each of these building blocks is independent, meaning that you can use one, some
 
 | Building Block | Description |
 |----------------|-------------|
-| **[Service Invocation]({{< ref service-invocation >}})** | 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 >}})** | With state management for storing 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 can include Azure CosmosDB, Azure SQL Server, PostgreSQL, AWS DynamoDB or Redis among others.
-| **[Publish and Subscribe Messaging]({{< ref pubsub >}})** | Publishing events and subscribing to topics | tween services enables event-driven architectures to simplify horizontal scalability and make them | silient to failure. Dapr provides at least once message delivery guarantee.
-| **[Resource Bindings]({{< ref bindings >}})** | 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 >}})** | A pattern for stateful and stateless objects that make concurrency simple with method and state encapsulation. Dapr provides many capabilities in its actor runtime including concurrency, state, life-cycle management for actor activation/deactivation and timers and reminders to wake-up actors.
-| **[Observability]({{< ref observability >}})** | Dapr emit metrics, logs, and traces to debug and monitor both Dapr and user applications. Dapr supports distributed tracing to easily diagnose and serve inter-service calls in production using the W3C Trace Context standard and Open Telemetry to send to different monitoring tools. 
-| **[Secrets]({{< ref secrets >}})** | Dapr provides secrets management and integrates with public cloud and local secret stores to retrieve the secrets for use in application code.
+| [**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 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 can include Azure CosmosDB, Azure SQL Server, PostgreSQL, AWS DynamoDB or Redis among others.
+| [**Publish and subscribe**]({{<ref "pubsub-overview.md">}}) | Publishing events and subscribing to topics | tween services enables event-driven architectures to simplify horizontal scalability and make them | silient to failure. Dapr provides at least once message delivery guarantee.
+| [**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 make concurrency simple with method and state encapsulation. Dapr provides many capabilities in its actor runtime including concurrency, state, life-cycle management for actor activation/deactivation and timers and reminders to wake-up actors.
+|  [**Observability**]({{<ref "observability-concept.md">}}) | Dapr emit metrics, logs, and traces to debug and monitor both Dapr and user applications. Dapr supports distributed tracing to easily diagnose and serve inter-service calls in production using the W3C Trace Context standard and Open Telemetry to send to different monitoring tools. 
+| [**Secrets**]({{<ref "secrets-overview.md">}}) | Dapr provides secrets management and integrates with public cloud and local secret stores to retrieve the secrets for use in application code.
 
 ## Sidecar architecture
 
@@ -82,7 +82,7 @@ Dapr can be used from  any developer framework. Here are some that have been int
  
  In the Dapr [Java SDK](https://github.com/dapr/java-sdk) you can find [Spring Boot](https://spring.io/) integration.
  
-Dapr integrates easily with Python [Flask](https://pypi.org/project/Flask/) and node [Express](http://expressjs.com/), which you can find in the [getting started samples](https://github.com/dapr/docs/tree/master/getting-started)
+Dapr integrates easily with Python [Flask](https://pypi.org/project/Flask/) and node [Express](http://expressjs.com/). See examples in the [Dapr quickstarts](https://github.com/dapr/quickstarts).
 
 #### Actors
 Dapr SDKs support for [virtual actors]({{< ref actors >}}) which are stateful objects that make concurrency simple, have method and state encapsulation, and are designed for scalable, distributed applications.
@@ -96,9 +96,9 @@ To enable developers to easily build workflow applications that use Dapr’s cap
 [cloud-native workflows using Dapr and Logic Apps](https://cloudblogs.microsoft.com/opensource/2020/05/26/announcing-cloud-native-workflows-dapr-logic-apps/) and visit the [Dapr workflow](https://github.com/dapr/workflows) repo to try out the samples.
 
 ## Designed for Operations
-Dapr is designed for operations. The [services dashboard](https://github.com/dapr/dashboard), installed via the Dapr CLI, provides a web-based UI enabling you to see information, view logs and more for the Dapr sidecars.
+Dapr is designed for [operations](/operations/). The [services dashboard](https://github.com/dapr/dashboard), installed via the Dapr CLI, provides a web-based UI enabling you to see information, view logs and more for the Dapr sidecars.
 
-The [monitoring]({{< ref monitoring >}}) provides deeper visibility into the Dapr system services and side-cars and the [observability]({{< ref observability >}}) of Dapr provide insights into your application such as tracing and metrics.
+The [monitoring tools support](/operations/monitoring/) provides deeper visibility into the Dapr system services and side-cars and the [observability capabilities]({{<ref "observability-concept.md">}}) of Dapr provide insights into your application such as tracing and metrics.
 
 ## Run anywhere
 
@@ -118,4 +118,4 @@ The `dapr-sentry` service is a certificate authority that enables mutual TLS bet
 
 <img src="/images/overview_kubernetes.png" width=800>
 
-Deploying and running a Dapr enabled application into your Kubernetes cluster is a simple as adding a few annotations to the deployment schemes. You can see some examples [here](https://github.com/dapr/quickstarts/tree/master/hello-kubernetes/deploy) in the Kubernetes getting started sample. Try this out with the [Kubernetes getting started sample](https://github.com/dapr/quickstarts/tree/master/hello-kubernetes)
+Deploying and running a Dapr enabled application into your Kubernetes cluster is a simple as adding a few annotations to the deployment schemes. You can see some examples [here](https://github.com/dapr/quickstarts/tree/master/hello-kubernetes/deploy) in the Kubernetes getting started sample. Try this out with the [Kubernetes quickstart](https://github.com/dapr/quickstarts/tree/master/hello-kubernetes).

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

@@ -73,11 +73,11 @@ The diagram below shows secure communication between the Dapr sidecar and the Da
 
 ## Component namespace scopes and secrets
 
-Dapr components are namespaced. That means a Dapr runtime sidecar instance can only access the components that have been deployed to the same namespace. See the [components scope topic]({{< ref component-scopes.md >}}) for more details.
+Dapr components are namespaced. That means a Dapr runtime sidecar instance can only access the components that have been deployed to the same namespace. See the [components scope documentation]({{<ref "component-scopes.md">}}) for more details.
 
-Dapr components uses Dapr's built-in secret management capability to manage secrets. See the [secret topic]({{< ref secrets >}}) for more details.
+Dapr components uses Dapr's built-in secret management capability to manage secrets. See the [secret store overview]({{<ref "secrets-overview.md">}}) for more details.
 
-In addition, Dapr offers application-level scoping for components by allowing users to specify which applications can consume given components.For more information about application level scoping, see [here]({{< ref "component-scopes.md#application-access-to-components-with-scopes" >}})
+In addition, Dapr offers application-level scoping for components by allowing users to specify which applications can consume given components.For more information about application level scoping, see [here]({{<ref "component-scopes.md#application-access-to-components-with-scopes">}}).
 
 ## Network security
 

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

@@ -6,7 +6,7 @@ weight: 10
 description: Overview of Dapr support for actors
 ---
 
-The Dapr actors runtime provides support for [virtual actors]({{< ref actors_background.md >}}) through following capabilities:
+The Dapr actors runtime provides support for [virtual actors]({{< ref actors-background.md >}}) through following capabilities:
 
 ## Actor method invocation
 

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

@@ -45,7 +45,7 @@ In order to invoke an output binding:
 1. Define the component YAML that describes the type of binding and its metadata (connection info, etc.)
 2. Use the HTTP endpoint or gRPC method to invoke the binding with an optional payload
 
-Read the [Send events to external systems using Output Bindings]({{< ref howto-bindings.md >}}) page to get started with output bindings.
+Read the [Send events to external systems using output bindings]({{< ref howto-bindings.md >}}) page to get started with output bindings.
 
 
 

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

@@ -12,11 +12,13 @@ This is ideal for event-driven processing, data pipelines or just generally reac
 
 Dapr bindings allow you to:
 
-- Receive events without including specific SDKs or libraries
-- Replace bindings without changing your code
-- Focus on business logic and not the event resource implementation
+* Receive events without including specific SDKs or libraries
+* Replace bindings without changing your code
+* Focus on business logic and not the event resource implementation
 
-For a complete sample showing bindings, visit this [link](https://github.com/dapr/quickstarts/tree/master/bindings).
+For more info on bindings, read [this overview]({{<ref bindings-overview.md>}}).
+
+For a quickstart sample showing bindings, visit this [link](https://github.com/dapr/quickstarts/tree/master/bindings).
 
 ## 1. Create a binding
 

daprdocs/content/en/developing-applications/building-blocks/pubsub/howto-publish-subscribe.md

@@ -1,6 +1,6 @@
 ---
 type: docs
-title: "How-To: Publish message and subscribe to a topic"
+title: "How-To: Publish a message and subscribe to a topic"
 linkTitle: "How-To: Publish & subscribe"
 weight: 2000
 description: "Learn how to send messages to a topic with one service and subscribe to that topic in another service"

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

@@ -1,6 +1,6 @@
 ---
 type: docs
-title: "Publish/Subscribe overview"
+title: "Publish and subscribe overview"
 linkTitle: "Overview"
 weight: 1000
 description: "Overview of the Dapr Pub/Sub building block"

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

@@ -30,7 +30,9 @@ The diagram below is an overview of how Dapr's service invocation works.
 1. Service A makes an http/gRPC call targeting Service B. The call goes to the local Dapr sidecar.  
 2. Dapr discovers Service B's location using the [name resolution component](https://github.com/dapr/components-contrib/tree/master/nameresolution) which is running on the given [hosting platform]({{< ref "hosting" >}}).
 3. Dapr forwards the message to Service B's Dapr sidecar 
-    * Note: All calls between Dapr sidecars go over gRPC for performance. Only calls between services and Dapr sidecars can be either HTTP or gRPC
+
+    **Note**: All calls between Dapr sidecars go over gRPC for performance. Only calls between services and Dapr sidecars can be either HTTP or gRPC
+
 4. Service B's Dapr sidecar forwards the request to the specified endpoint (or method) on Service B.  Service B then runs its business logic code.
 5. Service B sends a response to Service A.  The response goes to Service B's sidecar.
 6. Dapr forwards the response to Service A's Dapr sidecar.
@@ -53,7 +55,9 @@ For example, the following string contains the app ID `nodeapp` in addition to t
 localhost:3500/v1.0/invoke/nodeapp.production/method/neworder
 ```
 
-This is especially useful in cross namespace calls in a Kubernetes cluster. Watch this [video](https://youtu.be/LYYV_jouEuA?t=495) for a demo on how to use namespaces with service invocation.
+This is especially useful in cross namespace calls in a Kubernetes cluster. Watch this video for a demo on how to use namespaces with service invocation.
+
+<iframe width="560" height="315" src="https://www.youtube.com/embed/LYYV_jouEuA?start=497" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
 ### Retries
 
@@ -92,7 +96,7 @@ For more information read the [observability]({{< ref observability-concept.md >
 Dapr can run on any [hosting platform]({{< ref hosting >}}). For the supported hosting platforms this means they have a [name resolution component](https://github.com/dapr/components-contrib/tree/master/nameresolution) developed for them that enables service discovery. For example, the Kubernetes name resolution component uses the Kubernetes DNS service to resolve the location of other applications running in the cluster.
 
 ## Example
-Following the above call sequence, suppose you have the applications as described in the [hello world sample](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md), where a python app invokes a node.js app. In such a scenario, the python app would be "Service A" , and a Node.js app would be "Service B".
+Following the above call sequence, suppose you have the applications as described in the [hello world quickstart](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md), where a python app invokes a node.js app. In such a scenario, the python app would be "Service A" , and a Node.js app would be "Service B".
 
 The diagram below shows sequence 1-7 again on a local machine showing the API call:
 
@@ -111,5 +115,5 @@ The diagram below shows sequence 1-7 again on a local machine showing the API ca
 * Follow these guide on:
     * [How-to: Get started with HTTP service invocation]({{< ref howto-invoke-discover-services.md >}})
     * [How-to: Get started with Dapr and gRPC]({{< ref grpc >}})
-* Try out the [hello world sample](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md) which shows how to use HTTP service invocation or visit the samples in each of the [Dapr SDKs]({{< ref sdks >}})
+* Try out the [hello world quickstart](https://github.com/dapr/quickstarts/blob/master/hello-world/README.md) which shows how to use HTTP service invocation or visit the samples in each of the [Dapr SDKs]({{< ref sdks >}})
 * Read the [service invocation API specification]({{< ref service_invocation_api.md >}})

daprdocs/content/en/developing-applications/building-blocks/state-management/howto-stateful-service.md

@@ -24,7 +24,7 @@ To change the state store being used, replace the YAML under `/components` with
 
 ### Kubernetes
 
-See the instructions [here]({{< ref setup-state-store >}}) on how to setup different state stores on Kubernetes.
+See the instructions [here]({{<ref setup-state-store-overview>}}) on how to setup different state stores on Kubernetes.
 
 ## Strong and Eventual consistency
 

daprdocs/content/en/developing-applications/building-blocks/state-management/query-state-store/_index.md

@@ -5,3 +5,5 @@ linkTitle: "Backend stores"
 weight: 400
 description: "Guides for working with specific backend states stores"
 ---
+
+Explore the **Operations** section to see a list of [supported state stores]({{<ref supported-state-stores.md>}}) and how to setup [state store components]({{<ref setup-state-store-overview.md>}}).

daprdocs/content/en/developing-applications/building-blocks/state-management/query-state-store/query-redis-store.md

@@ -6,7 +6,7 @@ weight: 2000
 description: "Use Redis as a backend state store"
 ---
 
-Dapr doesn't transform state values while saving and retrieving states. Dapr requires all state store implementations to abide by a certain key format scheme (see [Dapr state management spec]({{< ref state_api.md >}}). You can directly interact with the underlying store to manipulate the state data, such querying states, creating aggregated views and making backups.
+Dapr doesn't transform state values while saving and retrieving states. Dapr requires all state store implementations to abide by a certain key format scheme (see [Dapr state management spec]({{<ref state_api.md>}}). You can directly interact with the underlying store to manipulate the state data, such querying states, creating aggregated views and making backups.
 
 >**NOTE:** The following examples uses Redis CLI against a Redis store using the default Dapr state store implementation.
 

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

@@ -22,13 +22,13 @@ See below for a diagram of state management's high level architecture.
 
 ## Features
 
-- [State Management API](#state-management-api)
-- [State Store Behaviors](#state-store-behaviors)
+- [State management API](#state-management-api)
+- [State store behaviors](#state-store-behaviors)
 - [Concurrency](#concurrency)
 - [Consistency](#consistency)
-- [Retry Policies](#retry-policies)
-- [Bulk Operations](#bulk-operations)
-- [Querying State Store Directly](#querying-state-store-directly)
+- [Retry policies](#retry-policies)
+- [Bulk operations](#bulk-operations)
+- [Querying state store directly](#querying-state-store-directly)
 
 ### State management API
 
@@ -62,7 +62,7 @@ The following table summarizes the capabilities of existing data store implement
 
 Dapr supports optimistic concurrency control (OCC) using ETags. When a state is requested, Dapr always attaches an **ETag** property to the returned state. And when the user code tries to update or delete a state, it's expected to attach the ETag through the **If-Match** header. The write operation can succeed only when the provided ETag matches with the ETag in the state store.
 
-Dapr chooses OCC because in many applications, data update conflicts are rare because clients are naturally partitioned by business contexts to operate on different data. However, if your application chooses to use ETags, a request may get rejected because of mismatched ETags. It's recommended that you use a [Retry Policy](#Retry-Policies) to compensate for such conflicts when using ETags.
+Dapr chooses OCC because in many applications, data update conflicts are rare because clients are naturally partitioned by business contexts to operate on different data. However, if your application chooses to use ETags, a request may get rejected because of mismatched ETags. It's recommended that you use a [retry policy](#Retry-Policies) to compensate for such conflicts when using ETags.
 
 If your application omits ETags in writing requests, Dapr skips ETag checks while handling the requests. This essentially enables the **last-write-wins** pattern, compared to the **first-write-wins** pattern with ETags.
 

daprdocs/content/en/getting-started/configure-redis.md

@@ -4,28 +4,20 @@ title: "How-To: Setup Redis"
 linkTitle: "How-To: Setup Redis"
 weight: 30
 description: "Configure Redis for Dapr state management or Pub/Sub"
-type: docs
 ---
 
-# Configure Redis for state management or pub/sub
-
 Dapr can use Redis in two ways:
 
 1. As state store component (state.redis) for persistence and restoration
 2. As pub/sub component (pubsub.redis) for async style message delivery
 
-- [Option 1: Creating a Redis Cache in your Kubernetes cluster using Helm](#Option-1:-creating-a-Redis-Cache-in-your-Kubernetes-Cluster-using-Helm)
-- [Option 2: Creating an Azure Cache for Redis service](#Option-2:-Creating-an-Azure-Cache-for-Redis-service)
-- [Configuration](#configuration)
-
-
 ## Creating a Redis store
 
 Dapr can use any Redis instance - containerized, running on your local dev machine, or a managed cloud service. If you already have a Redis store, move on to the [configuration](#configuration) section.
 
 ### Option 1: Creating a Redis Cache in your Kubernetes Cluster using Helm
 
-We can use [Helm](https://helm.sh/) to quickly create a Redis instance in our Kubernetes cluster. This approach requires [Installing Helm v3](https://github.com/helm/helm#install).
+You can use [Helm](https://helm.sh/) to quickly create a Redis instance in our Kubernetes cluster. This approach requires [Installing Helm v3](https://github.com/helm/helm#install).
 
 1. Install Redis into your cluster:
 
@@ -52,7 +44,7 @@ We can use [Helm](https://helm.sh/) to quickly create a Redis instance in our Ku
      value: redis-master.default.svc.cluster.local:6379
    ```
 
-4. Next, we'll get our Redis password using a `secretKeyRef` to a Kubernetes secret that has been configured into your cluster when Redis was installed. You can see the name of the secret key with `kubectl describe secret redis`
+4. Next, get the Redis password using a `secretKeyRef` to a Kubernetes secret that has been configured into your cluster when Redis was installed. You can see the name of the secret key with `kubectl describe secret redis`
 
 Add `redis` with the key `redis-password` as the `redisPassword` secretKeyRef in your [redis.yaml](#configuration) file. For example:
 
@@ -64,7 +56,7 @@ Add `redis` with the key `redis-password` as the `redisPassword` secretKeyRef in
    ```
 That's it! Now go to the [Configuration](#configuration) section
 
-5. (Alternative) Its **not recommended**, however you can use a hard coded password instead of secretKeyRef. First we'll get the Redis password, which is slightly different depending on the OS you're using:
+5. (Alternative) Its **not recommended**, however you can use a hard coded password instead of secretKeyRef. First you'll get the Redis password, which is slightly different depending on the OS you're using:
 
    - **Windows**: Run below commands
    ```powershell
@@ -95,14 +87,14 @@ That's it! Now go to the [Configuration](#configuration) section
 
 ### Option 2: Creating an Azure Cache for Redis service
 
-> **Note**: This approach requires having an Azure Subscription.
+> **Note**: This method requires having an Azure Subscription.
 
 1. Open the [Azure Portal](https://ms.portal.azure.com/#create/Microsoft.Cache) to start the Azure Redis Cache creation flow. Log in if necessary.
 1. Fill out the necessary information
 1. Click "Create" to kickoff deployment of your Redis instance.
 1. Once your instance is created, you'll need to grab your access key. Navigate to "Access Keys" under "Settings" and copy your key.
-1. We  need the hostname of your Redis instance, which we can retrieve from the "Overview" in Azure. It should look like `xxxxxx.redis.cache.windows.net:6380`.
-1. Finally, we need to add our key and our host to a `redis.yaml` file that Dapr can apply to our cluster. If you're running a sample, you'll add the host and key to the provided `redis.yaml`. If you're creating a project from the ground up, you'll create a `redis.yaml` file as specified in [Configuration](#configuration).
+1. You'll need the hostname of your Redis instance, which you can retrieve from the "Overview" in Azure. It should look like `xxxxxx.redis.cache.windows.net:6380`.
+1. Finally, you'll need to add our key and our host to a `redis.yaml` file that Dapr can apply to our cluster. If you're running a sample, you'll add the host and key to the provided `redis.yaml`. If you're creating a project from the ground up, you'll create a `redis.yaml` file as specified in [Configuration](#configuration).
 
    As the connection to Azure is encrypted, make sure to add the following block to the `metadata` section of your `redis.yaml` file.
 
@@ -112,7 +104,7 @@ That's it! Now go to the [Configuration](#configuration) section
      value: "true"
    ```
 
-> **NOTE:** Dapr pub/sub uses [Redis Streams](https://redis.io/topics/streams-intro) that was introduced by Redis 5.0, which isn't currently available on Azure Managed Redis Cache. Consequently, you can use Azure Managed Redis Cache only for state persistence.
+> **NOTE:** Dapr pub/sub uses [Redis streams](https://redis.io/topics/streams-intro) that was introduced by Redis 5.0, which isn't currently available on Azure Cache for Redis. Consequently, you can use Azure Cache for Redis only for state persistence.
 
 ### Other options to create a Redis database
 
@@ -121,7 +113,7 @@ That's it! Now go to the [Configuration](#configuration) section
 
 ## Configuration
 
-Dapr can use Redis as a `statestore` component for state persistence (`state.redis`) or as a `pubsub` component (`pubsub.redis`). The following yaml files demonstrates how to define each component using either a secretKey reference (which is preferred) or a plain text password. **Note:** In a production-grade application, follow [secret management]({{< ref secrets >}}) instructions to securely manage your secrets.
+Dapr can use Redis as a `statestore` component for state persistence (`state.redis`) or as a `pubsub` component (`pubsub.redis`). The following yaml files demonstrates how to define each component using either a secretKey reference (which is preferred) or a plain text password. **Note:** In a production-grade application, follow [secret management]({{<ref secrets-overview.md>}}) instructions to securely manage your secrets.
 
 ### Configuring Redis for state persistence using a secret key reference (preferred)
 
@@ -214,4 +206,4 @@ kubectl apply -f redis-pubsub.yaml
 
 By default the Dapr CLI creates a local Redis instance when you run `dapr init`. However, if you want to configure a different Redis instance, create a `components` dir containing the YAML file and provide the path to the `dapr run` command with the flag `--components-path`.
 
-If you initialized Dapr using `dapr init --slim`, the Dapr CLI did not create a Redis instance or a default configuration file for it. Follow [these instructions](#Creating-a-Redis-Store) to create a Redis store. Create the `redis.yaml` following the configuration [instructions](#Configuration) in a `components` dir and provide the path to the `dapr run` command with the flag `--components-path`.
+If you initialized Dapr using `dapr init --slim`, the Dapr CLI did not create a Redis instance or a default configuration file for it. Follow [these instructions](#creating-a-redis-store) to create a Redis store. Create the `redis.yaml` following the configuration [instructions](#configuration) in a `components` dir and provide the path to the `dapr run` command with the flag `--components-path`.

daprdocs/content/en/getting-started/install-dapr.md

@@ -4,14 +4,13 @@ title: "How-To: Setup Dapr environment"
 linkTitle: "How-To: Setup environment"
 weight: 20
 description: "Setup Dapr in a local environment or in a Kubernetes cluster"
-type: docs
 ---
 
 Dapr can be run in either self hosted or Kubernetes modes. Running Dapr runtime in self hosted mode enables you to develop Dapr applications in your local development environment and then deploy and run them in other Dapr supported environments. For example, you can develop Dapr applications in self hosted mode and then deploy them to any Kubernetes cluster.
 
 ## Prerequisites
 
-On default Dapr will install with a developer environment using Docker containers to get you started easily. However, Dapr does not depend on Docker to run (see [here](https://github.com/dapr/cli/blob/master/README.md) for instructions on installing Dapr locally without Docker using slim init). This getting started guide assumes Dapr is installed along with this developer environment.
+On default Dapr will install with a developer environment using Docker containers to get you started easily. However, Dapr does not depend on Docker to run (see [here](https://github.com/dapr/cli/blob/master/README.md#slim-init) for instructions on installing Dapr locally without Docker using slim init). This getting started guide assumes Dapr is installed along with this developer environment.
 
 - Install [Docker](https://docs.docker.com/install/)
 
@@ -64,7 +63,7 @@ Each release of Dapr CLI includes various OSes and architectures. These binary v
 
 On default, during initialization the Dapr CLI will install the Dapr binaries as well as setup a developer environment to help you get started easily with Dapr. This environment uses Docker containers, therefore Docker is listed as a prerequisite. 
 
->If you prefer to run Dapr without this environment and no dependency on Docker, see the CLI documentation for usage of the `--slim` flag with the init CLI command [here](https://github.com/dapr/cli/blob/master/README.md). Note, if you are a new user, it is strongly recommended to intall Docker and use the regular init command.
+>If you prefer to run Dapr without this environment and no dependency on Docker, see the CLI documentation for usage of the `--slim` flag with the init CLI command [here](https://github.com/dapr/cli/blob/master/README.md#slim-init). Note, if you are a new user, it is strongly recommended to intall Docker and use the regular init command.
 
 > For Linux users, if you run your docker cmds with sudo or the install path is `/usr/local/bin`(default install path), you need to use "**sudo dapr init**"
 > For Windows users, make sure that you run the cmd terminal in administrator mode
@@ -117,12 +116,12 @@ When setting up Kubernetes, you can do this either via the Dapr CLI or Helm.
 
 Dapr installs the following pods:
 
-* dapr-operator: Manages component updates and kubernetes services endpoints for Dapr (state stores, pub-subs, etc.)
+* dapr-operator: Manages component updates and Kubernetes services endpoints for Dapr (state stores, pub/subs, etc.)
 * dapr-sidecar-injector: Injects Dapr into annotated deployment pods
 * dapr-placement: Used for actors only. Creates mapping tables that map actor instances to pods
 * dapr-sentry: Manages mTLS between services and acts as a certificate authority
 
-### Setup Cluster
+### Setup cluster
 
 You can install Dapr on any Kubernetes cluster. Here are some helpful links:
 
@@ -132,7 +131,7 @@ You can install Dapr on any Kubernetes cluster. Here are some helpful links:
 - [Setup Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)
 
 > **Note:** Both the Dapr CLI, and the Dapr Helm chart automatically deploy with affinity for nodes with the label `kubernetes.io/os=linux`. You can deploy Dapr to Windows nodes, but most users should not need to.
-> For more information see [Deploying to a Hybrid Linux/Windows K8s Cluster]({{< ref kubernetes-hybrid-clusters >}})
+> For more information see [Deploying to a hybrid Linux/Windows Kubernetes cluster]({{<ref kubernetes-hybrid-clusters>}})
 
 ### Using the Dapr CLI
 
@@ -221,7 +220,7 @@ dapr-sentry-9435776c7f-8f7yd             1/1       Running   0          40s
 
 #### Sidecar annotations
 
-To see all the supported annotations for the Dapr sidecar on Kubernetes, visit [this]({{< ref kubernetes >}})  guide.
+To see all the supported annotations for the Dapr sidecar on Kubernetes, visit [this]({{<ref "kubernetes-annotations.md">}}) how to guide.
 
 #### Uninstall Dapr on Kubernetes