You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/aks/quickstart-event-grid.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,7 +21,7 @@ In this quickstart, you create an AKS cluster and subscribe to AKS events.
21
21
*[Azure CLI][azure-cli-install] or [Azure PowerShell][azure-powershell-install] installed.
22
22
23
23
> [!NOTE]
24
-
> In case there are issues specifically with EventGrid notifications, as can be seen here [Service Outages](https://azure.status.microsoft/status), please note that AKS operations wont be impacted and they are independent of Event Grid outages.
24
+
> In case there are issues specifically with EventGrid notifications, as can be seen here [Service Outages](https://azure.status.microsoft/status), please note that AKS operations won't be impacted and they are independent of Event Grid outages.
Copy file name to clipboardExpand all lines: articles/load-balancer/components.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,7 +39,7 @@ The group of virtual machines or instances in a virtual machine scale set that i
39
39
40
40
Load balancer instantly reconfigures itself via automatic reconfiguration when you scale instances up or down. Adding or removing VMs from the backend pool reconfigures the load balancer without other operations. The scope of the backend pool is any virtual machine in a single virtual network.
41
41
42
-
Backend pools support addition of instances via [network interface or IP addresses](backend-pool-management.md).
42
+
Backend pools support addition of instances via [network interface or IP addresses](backend-pool-management.md). VMs do not need a public IP address in order to be attached to backend pool of a public load balancer. Also, you can attach VMs to the backend pool of a load balancer even if they are in a stopped state.
43
43
44
44
When considering how to design your backend pool, design for the least number of individual backend pool resources to optimize the length of management operations. There's no difference in data plane performance or scale.
Copy file name to clipboardExpand all lines: articles/notification-hubs/firebase-migration-sdk.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,8 +16,8 @@ ms.lastreviewed: 03/01/2024
16
16
Google will deprecate the Firebase Cloud Messaging (FCM) legacy API by July 2024. You can begin migrating from the legacy HTTP protocol to FCM v1 on March 1, 2024. You must complete the migration by June 2024. This section describes the steps to migrate from FCM legacy to FCM v1 using the Azure SDKs.
17
17
18
18
## Prerequisites
19
-
20
-
To update your FCM credentials, [follow step 1 in the REST API guide](firebase-migration-rest.md#step-1-add-fcm-v1-credentials-to-hub).
19
+
- Ensure that **Firebase Cloud Messaging API (V1)** is enabled in Firebase project setting under **Cloud Messaging**.
20
+
- Ensure that FCM credentials are updated. [Follow step 1 in the REST API guide](firebase-migration-rest.md#step-1-add-fcm-v1-credentials-to-hub).
Copy file name to clipboardExpand all lines: articles/reliability/migrate-service-fabric.md
+1-143Lines changed: 1 addition & 143 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -79,149 +79,7 @@ Downtime for migrating Service Fabric non-managed clusters vary widely based on
79
79
80
80
## Migration for Service Fabric managed clusters
81
81
82
-
### Create new primary and secondary node types that span availability zones
83
-
84
-
There's only one method for migrating a non-availability zone enabled Service Fabric managed cluster to an availability zone enabled state.
85
-
86
-
**To migrate your Service Fabric managed cluster:**
87
-
88
-
1. Determine whether a new IP is required and what resources need to be migrated to become zone resilient. To get the current availability zone resiliency state for the resources of the managed cluster, use the following API call:
89
-
90
-
```http
91
-
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName}/getazresiliencystatus?api-version=2022-02-01-preview
If the Public IP resource isn't zone resilient, migration of the cluster causes a brief loss of external connectivity. The loss of connectivity is due to the migration setting up new Public IP and updating the cluster FQDN to the new IP. If the Public IP resource is zone resilient, migration will not modify the Public IP resource or FQDN and there will be no external connectivity impact.
123
-
124
-
1. Initiate conversion of the underlying storage account created for managed cluster from LRS to ZRS using [customer-initiated conversion](../storage/common/redundancy-migration.md#customer-initiated-conversion). The resource group of storage account that needs to be migrated would be of the form "SFC_ClusterId"(ex SFC_9240df2f-71ab-4733-a641-53a8464d992d) under the same subscription as the managed cluster resource.
125
-
126
-
1. Add a new primary node type, which spans across availability zones.
127
-
128
-
This step triggers the resource provider to perform the migration of the primary node type and Public IP along with a cluster FQDN DNS update, if needed, to become zone resilient. Use the above API to understand implication of this step.
129
-
130
-
* Use apiVersion 2022-02-01-preview or higher.
131
-
* Add a new primary node type to the cluster with zones parameter set to ["1", "2", "3"] as show below:
1. Add secondary node type, which spans across availability zones.
152
-
This step adds a secondary node type, which spans across availability zones similar to the primary node type. Once created, customers need to migrate existing services from the old node types to the new ones by [using placement properties](../service-fabric/service-fabric-cluster-resource-manager-cluster-description.md).
153
-
154
-
* Use apiVersion 2022-02-01-preview or higher.
155
-
* Add a new secondary node type to the cluster with zones parameter set to ["1", "2", "3"] as show below:
1. Start removing older non az spanning node types from the cluster
176
-
177
-
Once all your services are not present on your non zone spanned node types, you must remove the old node types. Start by [removing the old node types from the cluster](../service-fabric/how-to-managed-cluster-modify-node-type.md) using Portal or cmdlet. As a last step, remove any old node types from your template.
178
-
179
-
1. Mark the cluster resilient to zone failures
180
-
181
-
This step helps in future deployments, since it ensures that all future deployments of node types span across availability zones and so the cluster remains tolerant to zone failures. Set `zonalResiliency: true` in the cluster ARM template and do a deployment to mark the cluster as zone resilient and ensure all new node type deployments span across availability zones.
You can also see the updated status in portal under **Overview > Properties** similar to `Zonal resiliency True`, once complete.
191
-
192
-
1. Validate all the resources are zone resilient
193
-
194
-
To validate the availability zone resiliency state for the resources of the managed cluster use the following GET API call:
195
-
196
-
```http
197
-
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceFabric/managedClusters/{clusterName}/getazresiliencystatus?api-version=2022-02-01-preview
If you run into any problems, reach out to support for assistance.
224
-
82
+
Follow steps in [Migrate Service Fabric managed cluster to zone resilient](..\service-fabric\how-to-managed-cluster-availability-zones.md#migrate-an-existing-nonzone-resilient-cluster-to-zone-resilient-preview).
225
83
226
84
227
85
## Migration options for Service Fabric non-managed clusters
Copy file name to clipboardExpand all lines: articles/service-fabric/service-fabric-reliable-services-reliable-collections-guidelines.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,6 +37,7 @@ The guidelines are organized as simple recommendations prefixed with the terms *
37
37
* Do not perform any blocking code inside a transaction.
38
38
* When [string](/dotnet/api/system.string) is used as the key for a reliable dictionary, the sorting order uses [default string comparer CurrentCulture](/dotnet/api/system.string.compare#system-string-compare(system-string-system-string)). Note that the CurrentCulture sorting order is different from [Ordinal string comparer](/dotnet/api/system.stringcomparer.ordinal).
39
39
* Do not dispose or cancel a committing transaction. This is not supported and could crash the host process.
40
+
* Do ensure the operation order of different dictionaries stays the same for all concurrent transactions when reading or writing multiple dictionaries to avoid deadlock.
|**Windows**|PowerShell:`$env:AWS_ACCESS_KEY_ID=<access-key>`<br>`$env:AWS_SECRET_ACCESS_KEY=<secret-access-key>` <br> In a command prompt use: `set AWS_ACCESS_KEY_ID=<access-key>`<br>`set AWS_SECRET_ACCESS_KEY=<secret-access-key>`|
Copy file name to clipboardExpand all lines: articles/virtual-network/ip-services/public-ip-addresses.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -82,7 +82,7 @@ Public IP addresses are created with a SKU of **Standard** or **Basic**. The SK
82
82
> Basic SKU IPv4 addresses can be upgraded after creation to Standard SKU. To learn about SKU upgrade, refer to [Public IP upgrade](public-ip-upgrade-portal.md).
83
83
84
84
>[!IMPORTANT]
85
-
> Matching SKUs are required for load balancer and public IP resources. You can't have a mixture of basic SKU resources and standard SKU resources. You can't attach standalone virtual machines, virtual machines in an availability set resource, or a virtual machine scale set resources to both SKUs simultaneously. New designs should consider using Standard SKU resources. For more information about a standard load balancer, see [Standard Load Balancer](../../load-balancer/load-balancer-overview.md?toc=%2fazure%2fvirtual-network%2ftoc.json).
85
+
> Virtual machines attached to a backend pool do not need a public IP address to be attached to a public load balancer. But if they do, matching SKUs are required for load balancer and public IP resources. You can't have a mixture of basic SKU resources and standard SKU resources. You can't attach standalone virtual machines, virtual machines in an availability set resource, or a virtual machine scale set resources to both SKUs simultaneously. New designs should consider using Standard SKU resources. For more information about a standard load balancer, see [Standard Load Balancer](../../load-balancer/load-balancer-overview.md?toc=%2fazure%2fvirtual-network%2ftoc.json).
0 commit comments