Merge pull request #204773 from MicrosoftDocs/repo_sync_working_branch

huypub · web-flow · commit 843ee486df5d · 2022-07-14T14:58:42.000-07:00
Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)
diff --git a/articles/active-directory/verifiable-credentials/verifiable-credentials-configure-issuer.md b/articles/active-directory/verifiable-credentials/verifiable-credentials-configure-issuer.md
@@ -112,6 +112,12 @@ In this step, you create the verified credential expert card by using Azure AD V
             "required": false
           }
         ]
+      },
+      "validityInterval": 2592000,
+      "vc": {
+        "type": [
+        "VerifiedCredentialExpert"
+        ]
       }
     }
     ```
diff --git a/articles/azure-arc/data/concepts-distributed-postgres-hyperscale.md b/articles/azure-arc/data/concepts-distributed-postgres-hyperscale.md
@@ -31,7 +31,7 @@ The key concepts around Azure Arc-enabled PostgreSQL Hyperscale are summarized b
 [!INCLUDE [azure-arc-data-preview](../../../includes/azure-arc-data-preview.md)]
 
 ## Nodes and tables
-It is important to know about the following concepts to benefit the most from Azure Arc-enabled Postgres Hyperscale:
+It is important to know about the following concepts to benefit the most from Azure Arc-enabled PostgreSQL Hyperscale:
 - Specialized Postgres nodes in Azure Arc-enabled PostgreSQL Hyperscale: coordinator and workers
 - Types of tables: distributed tables, reference tables and local tables
 - Shards
@@ -41,7 +41,7 @@ See more information at [Nodes and tables in Azure Database for PostgreSQL – H
 ## Determine the application type
 Clearly identifying the type of application you are building is important. Why? 
 Because running efficient queries on a Azure Arc-enabled PostgreSQL Hyperscale server group requires that tables be properly distributed across servers. 
-The recommended distribution varies by the type of application and its query patterns. There are broadly two kinds of applications that work well on Azure Arc-enabled Postgres Hyperscale:
+The recommended distribution varies by the type of application and its query patterns. There are broadly two kinds of applications that work well on Azure Arc-enabled PostgreSQL Hyperscale:
 - Multi-Tenant Applications
 - Real-Time Applications
 
diff --git a/articles/azure-arc/data/create-postgresql-hyperscale-server-group-azure-data-studio.md b/articles/azure-arc/data/create-postgresql-hyperscale-server-group-azure-data-studio.md
@@ -56,18 +56,18 @@ In a few minutes, your creation should successfully complete.
 
 ### Important parameters you should consider:
 
-- **the number of worker nodes** you want to deploy to scale out and potentially reach better performances. Before proceeding here, read the [concepts about Postgres Hyperscale](concepts-distributed-postgres-hyperscale.md). The table below indicates the range of supported values and what form of Postgres deployment you get with them. For example, if you want to deploy a server group with 2 worker nodes, indicate 2. This will create three pods, one for the coordinator node/instance and two for the worker nodes/instances (one for each of the workers).
+- **the number of worker nodes** you want to deploy to scale out and potentially reach better performances. Before proceeding here, read the [concepts about PostgreSQL Hyperscale](concepts-distributed-postgres-hyperscale.md). The table below indicates the range of supported values and what form of Postgres deployment you get with them. For example, if you want to deploy a server group with 2 worker nodes, indicate 2. This will create three pods, one for the coordinator node/instance and two for the worker nodes/instances (one for each of the workers).
 
     |You need   |Shape of the server group you will deploy   |Number of worker nodes to indicate   |Note   |
     |---|---|---|---|
     |A scaled out form of Postgres to satisfy the scalability needs of your applications.   |3 or more Postgres instances, 1 is coordinator, n  are workers with n >=2.   |n, with n>=2.   |The Citus extension that provides the Hyperscale capability is loaded.   |
-    |A basic form of Postgres Hyperscale for you to do functional validation of your application at minimum cost. Not valid for performance and scalability validation. For that you need to use the type of deployments described above.   |1 Postgres instance that is both coordinator and worker.   |0 and add Citus to the list of extensions to load.   |The Citus extension that provides the Hyperscale capability is loaded.   |
+    |A basic form of PostgreSQL Hyperscale for you to do functional validation of your application at minimum cost. Not valid for performance and scalability validation. For that you need to use the type of deployments described above.   |1 Postgres instance that is both coordinator and worker.   |0 and add Citus to the list of extensions to load.   |The Citus extension that provides the Hyperscale capability is loaded.   |
     |A simple instance of Postgres that is ready to scale out when you need it.   |1 Postgres instance. It is not yet aware of the semantic for coordinator and worker. To scale it out after deployment, edit the configuration, increase the number of worker nodes and distribute the data.   |0   |The Citus extension that provides the Hyperscale capability is present on your deployment but is not yet loaded.   |
     |   |   |   |   |
 
     This table is demonstrated in the following figure:
 
-    :::image type="content" source="media/postgres-hyperscale/deployment-parameters.png" alt-text="Diagram that depicts Postgres Hyperscale worker node parameters and associated architecture." border="false":::
+    :::image type="content" source="media/postgres-hyperscale/deployment-parameters.png" alt-text="Diagram that depicts PostgreSQL Hyperscale worker node parameters and associated architecture." border="false":::
   
     While indicating 1 worker works, we do not recommend you use it. This deployment will not provide you much value. With it, you will get 2 instances of Postgres: 1 coordinator and 1 worker. With this setup you actually do not scale out the data since you deploy a single worker. As such you will not see an increased level of performance and scalability. We will remove the support of this deployment in a future release.
  
@@ -82,7 +82,7 @@ In a few minutes, your creation should successfully complete.
 ## Next steps
 - [Manage your server group using Azure Data Studio](manage-postgresql-hyperscale-server-group-with-azure-data-studio.md)
 - [Monitor your server group](monitor-grafana-kibana.md)
-- Read the concepts and How-to guides of Azure Database for PostgreSQL Hyperscale to distribute your data across multiple PostgreSQL Hyperscale nodes and to benefit from all the power of Azure Database for Postgres Hyperscale. :
+- Read the concepts and How-to guides of Azure Database for PostgreSQL Hyperscale to distribute your data across multiple PostgreSQL Hyperscale nodes and to benefit from all the power of Azure Database for PostgreSQL Hyperscale. :
     * [Nodes and tables](../../postgresql/hyperscale/concepts-nodes.md)
     * [Determine application type](../../postgresql/hyperscale/howto-app-type.md)
     * [Choose a distribution column](../../postgresql/hyperscale/howto-choose-distribution-column.md)
diff --git a/articles/azure-arc/data/create-postgresql-hyperscale-server-group-azure-portal.md b/articles/azure-arc/data/create-postgresql-hyperscale-server-group-azure-portal.md
@@ -92,7 +92,7 @@ Be aware of the following considerations when you're deploying:
 
     This table is demonstrated in the following figure:
 
-    :::image type="content" source="media/postgres-hyperscale/deployment-parameters.png" alt-text="Diagram that depicts Postgres Hyperscale worker node parameters and associated architecture." border="false":::  
+    :::image type="content" source="media/postgres-hyperscale/deployment-parameters.png" alt-text="Diagram that depicts PostgreSQL Hyperscale worker node parameters and associated architecture." border="false":::  
 
     Although you can indicate *1* worker, it's not a good idea to do so. This deployment doesn't provide you with much value. With it, you get two instances of Azure Arc-enabled PostgreSQL Hyperscale: one coordinator and one worker. You don't scale out the data because you deploy a single worker. As such, you don't see an increased level of performance and scalability.
 
diff --git a/articles/azure-arc/data/create-postgresql-hyperscale-server-group.md b/articles/azure-arc/data/create-postgresql-hyperscale-server-group.md
@@ -56,20 +56,20 @@ The main parameters should consider are:
 
 - **the version of the PostgreSQL engine** you want to deploy: by default it is version 12. To deploy version 12, you can either omit this parameter or pass one of the following parameters: `--engine-version 12` or `-ev 12`. To deploy version 11, indicate `--engine-version 11` or `-ev 11`.
 
-- **the number of worker nodes** you want to deploy to scale out and potentially reach better performances. Before proceeding here, read the [concepts about Postgres Hyperscale](concepts-distributed-postgres-hyperscale.md). To indicate the number of worker nodes to deploy, use the parameter `--workers` or `-w` followed by an integer. The table below indicates the range of supported values and what form of Postgres deployment you get with them. For example, if you want to deploy a server group with two worker nodes, indicate `--workers 2` or `-w 2`. This will create three pods, one for the coordinator node/instance and two for the worker nodes/instances (one for each of the workers).
+- **the number of worker nodes** you want to deploy to scale out and potentially reach better performances. Before proceeding here, read the [concepts about PostgreSQL Hyperscale](concepts-distributed-postgres-hyperscale.md). To indicate the number of worker nodes to deploy, use the parameter `--workers` or `-w` followed by an integer. The table below indicates the range of supported values and what form of Postgres deployment you get with them. For example, if you want to deploy a server group with two worker nodes, indicate `--workers 2` or `-w 2`. This will create three pods, one for the coordinator node/instance and two for the worker nodes/instances (one for each of the workers).
 
 
 
     |You need   |Shape of the server group you will deploy   |`-w` parameter to use   |Note   |
     |---|---|---|---|
     |A scaled out form of Postgres to satisfy the scalability needs of your applications.   |Three or more Postgres instances, one is coordinator, n  are workers with n >=2.   |Use `-w n`, with n>=2.   |The Citus extension that provides the Hyperscale capability is loaded.   |
-    |A basic form of Postgres Hyperscale for you to do functional validation of your application at minimum cost. Not valid for performance and scalability validation. For that you need to use the type of deployments described above.   |One Postgres instance that is both coordinator and worker.   |Use `-w 0` and load the Citus extension. Use the following parameters if deploying from command line: `-w 0` --extensions Citus.   |The Citus extension that provides the Hyperscale capability is loaded.   |
+    |A basic form of PostgreSQL Hyperscale for you to do functional validation of your application at minimum cost. Not valid for performance and scalability validation. For that you need to use the type of deployments described above.   |One Postgres instance that is both coordinator and worker.   |Use `-w 0` and load the Citus extension. Use the following parameters if deploying from command line: `-w 0` --extensions Citus.   |The Citus extension that provides the Hyperscale capability is loaded.   |
     |A simple instance of Postgres that is ready to scale out when you need it.   |One Postgres instance. It is not yet aware of the semantic for coordinator and worker. To scale it out after deployment, edit the configuration, increase the number of worker nodes and distribute the data.   |Use `-w 0` or do not specify `-w`.   |The Citus extension that provides the Hyperscale capability is present on your deployment but is not yet loaded.   |
     |   |   |   |   |
 
     This table is demonstrated in the following figure:
 
-    :::image type="content" source="media/postgres-hyperscale/deployment-parameters.png" alt-text="Diagram that depicts Postgres Hyperscale worker node parameters and associated architecture." border="false":::
+    :::image type="content" source="media/postgres-hyperscale/deployment-parameters.png" alt-text="Diagram that depicts PostgreSQL Hyperscale worker node parameters and associated architecture." border="false":::
 
     While using `-w 1` works, we do not recommend you use it. This deployment will not provide you much value. With it, you will get two instances of Postgres: One coordinator and one worker. With this setup, you actually do not scale out the data since you deploy a single worker. As such you will not see an increased level of performance and scalability. We will remove the support of this deployment in a future release.
 
diff --git a/articles/azure-arc/data/migrate-postgresql-data-into-postgresql-hyperscale-server-group.md b/articles/azure-arc/data/migrate-postgresql-data-into-postgresql-hyperscale-server-group.md
@@ -210,6 +210,6 @@ Within your Arc setup you can use `psql` to connect to your Postgres instance, s
     * [Design a multi-tenant database](../../postgresql/hyperscale/tutorial-design-database-multi-tenant.md)*
     * [Design a real-time analytics dashboard](../../postgresql/hyperscale/tutorial-design-database-realtime.md)*
 
-> *In these documents, skip the sections **Sign in to the Azure portal**, and **Create an Azure Database for Postgres - Hyperscale (Citus)**. Implement the remaining steps in your Azure Arc deployment. Those sections are specific to the Azure Database for PostgreSQL Hyperscale (Citus) offered as a PaaS service in the Azure cloud but the other parts of the documents are directly applicable to your Azure Arc-enabled PostgreSQL Hyperscale.
+> *In these documents, skip the sections **Sign in to the Azure portal**, and **Create an Azure Database for PostgreSQL - Hyperscale (Citus)**. Implement the remaining steps in your Azure Arc deployment. Those sections are specific to the Azure Database for PostgreSQL Hyperscale (Citus) offered as a PaaS service in the Azure cloud but the other parts of the documents are directly applicable to your Azure Arc-enabled PostgreSQL Hyperscale.
 
 - [Scale out your Azure Database for PostgreSQL Hyperscale server group](scale-out-in-postgresql-hyperscale-server-group.md)
diff --git a/articles/azure-arc/data/restore-adventureworks-sample-db-into-postgresql-hyperscale-server-group.md b/articles/azure-arc/data/restore-adventureworks-sample-db-into-postgresql-hyperscale-server-group.md
@@ -32,7 +32,7 @@ Run a command like this to download the files replace the value of the pod name
 >  Your container will need to have Internet connectivity over 443 to download the file from GitHub.
 
 > [!NOTE]
->  Use the pod name of the Coordinator node of the Postgres Hyperscale server group. Its name is \<server group name\>c-0 (for example postgres01c-0, where c stands for Coordinator node).  If you are not sure of the pod name run the command `kubectl get pod`
+>  Use the pod name of the Coordinator node of the PostgreSQL Hyperscale server group. Its name is \<server group name\>c-0 (for example postgres01c-0, where c stands for Coordinator node).  If you are not sure of the pod name run the command `kubectl get pod`
 
 ```console
 kubectl exec <PostgreSQL pod name> -n <namespace name> -c postgres  -- /bin/bash -c "cd /tmp && curl -k -O https://raw.githubusercontent.com/microsoft/azure_arc/main/azure_arc_data_jumpstart/cluster_api/capi_azure/arm_template/artifacts/AdventureWorks2019.sql"
diff --git a/articles/azure-arc/data/scale-out-in-postgresql-hyperscale-server-group.md b/articles/azure-arc/data/scale-out-in-postgresql-hyperscale-server-group.md
@@ -14,9 +14,9 @@ ms.topic: how-to
 # Scale out and in your Azure Arc-enabled PostgreSQL Hyperscale server group by adding more worker nodes
 This document explains how to scale out and scale in an Azure Arc-enabled PostgreSQL Hyperscale server group. It does so by taking you through a scenario. **If you do not want to run through the scenario and want to just read about how to scale out, jump to the paragraph [Scale out](#scale-out)** or [Scale in]().
 
-You scale out when you add Postgres instances (Postgres Hyperscale worker nodes) to your Azure Arc-enabled PosrgreSQL Hyperscale server group.
+You scale out when you add Postgres instances (PostgreSQL Hyperscale worker nodes) to your Azure Arc-enabled PosrgreSQL Hyperscale server group.
 
-You scale in when you remove Postgres instances (Postgres Hyperscale worker nodes) from your Azure Arc-enabled PosrgreSQL Hyperscale server group.
+You scale in when you remove Postgres instances (PostgreSQL Hyperscale worker nodes) from your Azure Arc-enabled PosrgreSQL Hyperscale server group.
 
 
 [!INCLUDE [azure-arc-data-preview](../../../includes/azure-arc-data-preview.md)]
@@ -264,7 +264,7 @@ The scale-in operation is an online operation. Your applications continue to acc
 
 - Read about how to [scale up and down (memory, vCores) your Azure Arc-enabled PostgreSQL Hyperscale server group](scale-up-down-postgresql-hyperscale-server-group-using-cli.md)
 - Read about how to set server parameters in your Azure Arc-enabled PostgreSQL Hyperscale server group
-- Read the concepts and How-to guides of Azure Database for PostgreSQL Hyperscale to distribute your data across multiple PostgreSQL Hyperscale nodes and to benefit from all the power of Azure Database for Postgres Hyperscale. :
+- Read the concepts and How-to guides of Azure Database for PostgreSQL Hyperscale to distribute your data across multiple PostgreSQL Hyperscale nodes and to benefit from all the power of Azure Database for PostgreSQL Hyperscale. :
     * [Nodes and tables](../../postgresql/hyperscale/concepts-nodes.md)
     * [Determine application type](../../postgresql/hyperscale/howto-app-type.md)
     * [Choose a distribution column](../../postgresql/hyperscale/howto-choose-distribution-column.md)
diff --git a/articles/azure-cache-for-redis/cache-reserved-pricing.md b/articles/azure-cache-for-redis/cache-reserved-pricing.md
@@ -29,6 +29,8 @@ The size of reservation should be based on the total amount of memory size that
 
 For example, let's suppose that you're running two caches - one at 13 GB and the other at 26 GB. You'll need both for at least one year. Further, let's suppose that you plan to scale the existing 13-GB caches to 26 GB for a month to meet your seasonal demand, and then scale back. In this case, you can purchase either one P2-cache and one P3-cache or three P2-caches on a one-year reservation to maximize savings. You'll receive discount on the total amount of cache memory you reserve, independent of how that amount is allocated across your caches.
 
+Reserved capacity is sold in increments of nodes. Each shard contains 2 nodes by default. To buy reserved capacity for a shard, you buy 2 reserved capacity. For the number of nodes calculation, see "View Cost Calculation" on [Pricing calculator](https://azure.microsoft.com/pricing/calculator/). For an explanation of the architecture of a cache, see [A quick summary of cache architecture](cache-failover.md#a-quick-summary-of-cache-architecture).
+
 ## Buy Azure Cache for Redis reserved capacity
 
 You can buy a reserved VM instance in the [Azure portal](https://portal.azure.com/#blade/Microsoft_Azure_Reservations/CreateBlade/). Pay for the reservation [up front or with monthly payments](../cost-management-billing/reservations/prepare-buy-reservation.md).
diff --git a/articles/cognitive-services/Speech-Service/rest-speech-to-text-v3-1.md b/articles/cognitive-services/Speech-Service/rest-speech-to-text-v3-1.md
@@ -48,10 +48,10 @@ Use the REST API v3.1 to:
  ```json 
  "features": {
          …
-          "supportsAdaptationsWith": [
-           “Acoustic”,
-           "Language",
-           “LanguageMarkdown”,
+            "supportsAdaptationsWith": [
+            "Acoustic",
+            "Language",
+            "LanguageMarkdown",
             "Pronunciation"
           ]
    }
diff --git a/articles/cost-management-billing/costs/group-filter.md b/articles/cost-management-billing/costs/group-filter.md
@@ -33,7 +33,7 @@ The following table lists some of the most common grouping and filtering options
 | **Frequency** | Break down usage-based, one-time, and recurring costs. | |
 | **Invoice ID** | Break down costs by billed invoice. | Unbilled charges don't have an invoice ID yet and EA costs don't include invoice details and will show as **No invoice ID**.  |
 | **Location** | Break down costs by resource location or region. | Purchases and Marketplace usage may be shown as **unassigned**, or **No resource location**. |
-| **Meter** | Break down costs by usage meter. | Purchases and Marketplace usage will show as **No meter**. Refer to **Charge type** to identify purchases and **Publisher type** to identify Marketplace charges. |
+| **Meter** | Break down costs by usage meter. | Purchases and Marketplace usage will show as **unassigned** or **No meter**. Refer to **Charge type** to identify purchases and **Publisher type** to identify Marketplace charges. |
 | **Operation** | Break down AWS costs by operation. | Applicable only to AWS scopes and management groups. Azure data doesn't include operation and will show as **No operation** - use **Meter** instead. |
 | **Pricing model** | Break down costs by on-demand, reservation, or spot usage. | Purchases show as **OnDemand**. If you see **Not applicable**, group by **Reservation** to determine whether the usage is reservation or on-demand usage and **Charge type** to identify purchases.
 | **Provider** | Break down costs by the provider type: Azure, Microsoft 365, Dynamics 365, AWS, and so on. | Identifier for product and line of business. |
diff --git a/articles/cost-management-billing/understand/review-individual-bill.md b/articles/cost-management-billing/understand/review-individual-bill.md
@@ -88,7 +88,6 @@ Your usage charges are displayed at the meter level. The following terms mean th
 |Resource |MeterName |
 |Region |MeterRegion |
 |Consumed | Quantity |
-|Included |Included Quantity |
 |Billable |Overage Quantity |
 |Rate | EffectivePrice|
 | Value | Cost |
diff --git a/articles/virtual-machines/delete.md b/articles/virtual-machines/delete.md

Original file line number	Diff line number	Diff line change
`@@ -112,6 +112,12 @@ In this step, you create the verified credential expert card by using Azure AD V`
`112`	`112`	`"required": false`
`113`	`113`	`}`
`114`	`114`	`]`
	`115`	`+ },`
	`116`	`+ "validityInterval": 2592000,`
	`117`	`+ "vc": {`
	`118`	`+ "type": [`
	`119`	`+ "VerifiedCredentialExpert"`
	`120`	`+ ]`
`115`	`121`	`}`
`116`	`122`	`}`
`117`	`123`	```