Upmerge 1.7 into 1.8 [2022-06-20]

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

@@ -12,53 +12,61 @@ Dapr uses a modular design where functionality is delivered as a component. Each
 
  You can get a list of current components available in the hosting environment using the `dapr components` CLI command.
 
+## Component specification
+
+Each component has a specification (or spec) that it conforms to. Components are configured at design-time with a YAML file which is stored in either a `components/local` folder within your solution, or globally in the `.dapr` folder created when invoking `dapr init`. These YAML files adhere to the generic [Dapr component schema]({{<ref "component-schema.md">}}), but each is specific to the component specification. 
+
+It is important to understand that the component spec values, particularly the spec `metadata`, can change between components of the same component type, for example between different state stores, and that some design-time spec values can be overridden at runtime when making requests to a component's API. As a result, it is strongly recommended to review a [component's specs]({{<ref "components-reference">}}), paying particular attention to the sample payloads for requests to set the metadata used to interact with the component.
+
+## Available component types
+
 The following are the component types provided by Dapr:
 
-## State stores
+### 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
 
 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.
 
 - [List of name resolution components]({{< ref supported-name-resolution >}})
 - [Name resolution implementations](https://github.com/dapr/components-contrib/tree/master/nameresolution)
 
-## Pub/sub brokers
+### Pub/sub brokers
 
 Pub/sub broker components are message brokers that can pass messages to/from services as part of the [publish & subscribe]({{< ref pubsub-overview.md >}}) building block.
 
 - [List of pub/sub brokers]({{< ref supported-pubsub >}})
 - [Pub/sub broker implementations](https://github.com/dapr/components-contrib/tree/master/pubsub)
 
-## Bindings
+### 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.
 
 - [List of supported bindings]({{< ref supported-bindings >}})
 - [Binding implementations](https://github.com/dapr/components-contrib/tree/master/bindings)
 
-## Secret stores
+### Secret stores
 
 A [secret]({{<ref "secrets-overview.md">}}) is any piece of private information that you want to guard against unwanted access. Secrets stores are used to store secrets that can be retrieved and used in applications.
 
 - [List of supported secret stores]({{< ref supported-secret-stores >}})
 - [Secret store implementations](https://github.com/dapr/components-contrib/tree/master/secretstores)
 
-## Configuration stores
+### Configuration stores
 
 Configuration stores are used to save application data, which can then be read by application instances on startup or notified of when changes occur. This allows for dynamic configuration.
 
 - [List of supported configuration stores]({{< ref supported-configuration-stores >}})
 - [Configuration store implementations](https://github.com/dapr/components-contrib/tree/master/configuration)
 
-## Middleware
+### Middleware
 
-Dapr allows custom [middleware]({{<ref "middleware.md">}})  to be plugged into the HTTP request processing pipeline. Middleware can perform additional actions on an HTTP 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.
+Dapr allows custom [middleware]({{<ref "middleware.md">}})  to be plugged into the HTTP request processing pipeline. Middleware can perform additional actions on an HTTP request, such as authentication, encryption and message transformation before the request is routed to the user code, or before the response is returned to the client. The middleware components are used with the [service invocation]({{<ref "service-invocation-overview.md">}}) building block.
 
 - [List of supported middleware components]({{< ref supported-middleware >}})
 - [Middleware implementations](https://github.com/dapr/components-contrib/tree/master/middleware)

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

@@ -6,8 +6,13 @@ weight: 100
 description: "Overview of the Dapr sidecar process"
 ---
 
-Dapr uses a [sidecar pattern]({{< ref "concepts/overview.md#sidecar-architecture" >}}), meaning the Dapr APIs are run and exposed on a separate process (i.e. the Dapr sidecar) running alongside your application. The Dapr sidecar process is named `daprd` and is launched in different ways depending on the hosting environment.
+Dapr uses a [sidecar pattern]({{< ref "concepts/overview.md#sidecar-architecture" >}}), meaning the Dapr APIs are run and exposed on a separate process, the Dapr sidecar, running alongside your application. The Dapr sidecar process is named `daprd` and is launched in different ways depending on the hosting environment.
 
+The Dapr sidecar exposes [building block APIs]({{<ref building-blocks-concept>}}) used by your application business logic, a [metadata API]({{<ref metadata_api>}}) for discoverability of capabiliites and to set attributes and a [health API]({{<ref sidecar-health>}}) to determine health status. 
+
+<img src="/images/overview-sidecar-apis.png" width=700>
+
+The sidecar APIs are called from your application over local http or gRPC endpoints. 
 <img src="/images/overview-sidecar-model.png" width=700>
 
 ## Self-hosted with `dapr run`
@@ -20,13 +25,13 @@ On [Kubernetes]({{< ref kubernetes.md >}}), the Dapr control plane includes the
 
 ## Running the sidecar directly
 
-In most cases you do not need to run `daprd` explicitly, as the sidecar is either launched by the CLI (self-hosted mode) or by the dapr-sidecar-injector service (Kubernetes). For advanced use cases (debugging, scripted deployments, etc.) the `daprd` process can be launched directly.
+In most cases you do not need to run `daprd` explicitly, as the sidecar is either launched by the [CLI]({{<ref cli-overview>}}) (self-hosted mode) or by the dapr-sidecar-injector service (Kubernetes). For advanced use cases (debugging, scripted deployments, etc.) the `daprd` process can be launched directly.
 
 For a detailed list of all available arguments run `daprd --help` or see this [table]({{< ref arguments-annotations-overview.md >}}) which outlines how the `daprd` arguments relate to the CLI arguments and Kubernetes annotations.
 
 ### Examples
 
-1. Start a sidecar along an application by specifying its unique ID. Note `--app-id` is a required field:
+1. Start a sidecar along with an application by specifying its unique ID. Note `--app-id` is a required field:
 
    ```bash
    daprd --app-id myapp