Merge branch 'v1.1' into aacrawfi/sql-actors

daprdocs/content/en/developing-applications/integrations/autoscale-keda.md

@@ -1,7 +1,8 @@
 ---
 type: docs
 title: "Autoscaling a Dapr app with KEDA"
-linkTitle: "Autoscale"
+linkTitle: "Autoscale with KEDA"
+description: "How to configure your Dapr application to autoscale using KEDA"
 weight: 2000
 ---
 
@@ -9,7 +10,7 @@ Dapr, with its modular building-block approach, along with the 10+ different [pu
 
 For Kubernetes, Dapr integrates with [KEDA](https://github.com/kedacore/keda), an event driven autoscaler for Kubernetes. Many of Dapr's pub/sub components overlap with the scalers provided by [KEDA](https://github.com/kedacore/keda) so it's easy to configure your Dapr deployment on Kubernetes to autoscale based on the back pressure using KEDA. 
 
-This how-to walks through the configuration of a scalable Dapr application along with the back pressure on Kafka topic, however you can apply this approach to [pub/sub components]({{< ref pubsub >}}) offered by Dapr.
+This how-to walks through the configuration of a scalable Dapr application along with the back pressure on Kafka topic, however you can apply this approach to any [pub/sub components]({{< ref pubsub >}}) offered by Dapr.
 
 ## Install KEDA
 
@@ -138,4 +139,4 @@ All done!
 
 Now, that the `ScaledObject` KEDA object is configured, your deployment will scale based on the lag of the Kafka topic. More information on configuring KEDA for Kafka topics is available [here](https://keda.sh/docs/2.0/scalers/apache-kafka/).
 
-You can now start publishing messages to your Kafka topic `demo-topic` and watch the pods autoscale when the lag threshold is higher than `5` topics, as we have defined in the KEDA scaler manifest. You can publish messages to the Kafka Dapr component by using the Dapr [Publish](https://github.com/dapr/CLI#publishsubscribe) CLI command
+You can now start publishing messages to your Kafka topic `demo-topic` and watch the pods autoscale when the lag threshold is higher than `5` topics, as we have defined in the KEDA scaler manifest. You can publish messages to the Kafka Dapr component by using the Dapr [Publish]({{< ref dapr-publish >}}) CLI command

daprdocs/content/en/developing-applications/integrations/azure-functions.md

@@ -0,0 +1,10 @@
+---
+type: docs
+title: "Dapr extension for Azure Functions runtime"
+linkTitle: "Azure Functions"
+description: "Access Dapr capabilities from your Functions runtime application"
+weight: 3000
+---
+
+Dapr integrates with the Azure Functions runtime via an extension that lets a function seamlessly interact with Dapr. Azure Functions provides an event-driven programming model and Dapr provides cloud-native building blocks. With this  extension, you can bring both together for serverless and event-driven apps. For more information read
+[Azure Functions extension for Dapr](https://cloudblogs.microsoft.com/opensource/2020/07/01/announcing-azure-functions-extension-for-dapr/) and visit the [Azure Functions extension](https://github.com/dapr/azure-functions-extension) repo to try out the samples.

daprdocs/content/en/developing-applications/integrations/cloud-providers/_index.md

@@ -1,7 +1,7 @@
 ---
 type: docs
-title: "Authenticating to services"
-linkTitle: "Authenticating to services"
-weight: 3000
+title: "Integrations with cloud providers"
+linkTitle: "Cloud providers"
+weight: 5000
 description: "Information about authentication and configuration for various cloud providers"
 ---

daprdocs/content/en/developing-applications/integrations/cloud-providers/authenticating-aws.md

@@ -4,6 +4,8 @@ title: "Authenticating to AWS"
 linkTitle: "Authenticating to AWS"
 weight: 10
 description: "Information about authentication and configuration options for AWS"
+aliases:
+  - /developing-applications/integrations/authenticating/authenticating-aws/
 ---
 
 All Dapr components using various AWS services (DynamoDB, SQS, S3, etc) use a standardized set of attributes for configuration, these are described below.
@@ -12,11 +14,11 @@ All Dapr components using various AWS services (DynamoDB, SQS, S3, etc) use a st
 
 None of the following attributes are required, since the AWS SDK may be configured using the default provider chain described in the link above. It's important to test the component configuration and inspect the log output from the Dapr runtime to ensure that components initialize correctly.
 
-`region`: Which AWS region to connect to. In some situations (when running Dapr in self-hosted mode, for example) this flag can be provided by the environment variable `AWS_REGION`. Since Dapr sidecar injection doesn't allow configuring environment variables on the Dapr sidecar, it is recommended to always set the `region` attribute in the component spec.   
-`endpoint`: The endpoint is normally handled internally by the AWS SDK. However, in some situations it might make sense to set it locally - for example if developing against [DynamoDB Local](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html).   
-`accessKey`: AWS Access key id.   
-`secretKey`: AWS Secret access key. Use together with `accessKey` to explicitly specify credentials.   
-`sessionToken`: AWS Session token. Used together with `accessKey` and `secretKey`. When using a regular IAM user's access key and secret, a session token is normally not required.
+- `region`: Which AWS region to connect to. In some situations (when running Dapr in self-hosted mode, for example) this flag can be provided by the environment variable `AWS_REGION`. Since Dapr sidecar injection doesn't allow configuring environment variables on the Dapr sidecar, it is recommended to always set the `region` attribute in the component spec.   
+- `endpoint`: The endpoint is normally handled internally by the AWS SDK. However, in some situations it might make sense to set it locally - for example if developing against [DynamoDB Local](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html).   
+- `accessKey`: AWS Access key id.   
+- `secretKey`: AWS Secret access key. Use together with `accessKey` to explicitly specify credentials.   
+- `sessionToken`: AWS Session token. Used together with `accessKey` and `secretKey`. When using a regular IAM user's access key and secret, a session token is normally not required.
 
 ## Alternatives to explicitly specifying credentials in component manifest files
 In production scenarios, it is recommended to use a solution such as [Kiam](https://github.com/uswitch/kiam) or [Kube2iam](https://github.com/jtblin/kube2iam). If running on AWS EKS, you can [link an IAM role to a Kubernetes service account](https://docs.aws.amazon.com/eks/latest/userguide/create-service-account-iam-policy-and-role.html), which your pod can use.

daprdocs/content/en/developing-applications/integrations/gRPC-integration.md

@@ -1,7 +1,7 @@
 ---
 type: docs
 title: "Dapr's gRPC Interface"
-linkTitle: "gRPC"
+linkTitle: "gRPC interface"
 weight: 1000
 description: "Use the Dapr gRPC API in your application"
 type: docs

daprdocs/content/en/developing-applications/integrations/workflows.md

@@ -0,0 +1,9 @@
+---
+type: docs
+title: "Build workflows with Logic Apps"
+linkTitle: "Workflows"
+description: "Learn how to build workflows using Dapr Workflows and Logic Apps"
+weight: 4000
+---
+
+To enable developers to easily build workflow applications that use Dapr’s capabilities including diagnostics and multi-language support, you can use Dapr workflows. Dapr integrates with workflow engines such as Logic Apps runtime.  For more information read [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.