OCPBUGS-13300: masters on a single compute server group

2.5 years ago we allowed to configure `serverGroupPolicy` in
install-config so a user could choose which Nova scheduling policy
to adopt for the machines.

However, if the masters were configured with AZ, Terraform would
create one ServerGroup in OpenStack (the one from master-0) but
configure the Machine providerSpec with different ServerGroups, one
per AZ. This was unwanted and now we want to use a single ServerGroup
for masters.

With compute AZ support, the users already have the possibility to
ensure that masters aren't on the same failure domain as others.
Also, even if there is less than 3 AZs (e.g. 2), the default
`soft-anti-affinity` server group policy would make Nova to
scheduling in best effort the machines on different hosts within a same
AZ.

Therefore, there is no need to configure the master machines with a
`serverGroup` per availability zone in their Machines.

Also, note that in OCP 4.14, CPMS will be enabled by default.
If a user has set multiple AZ for the controlPlane and upgrade from
4.13 to 4.14, CPMS will adopt the control plane and create a CPMS in
Inactive mode, with a single `serverGroup`. The `serverGroup` will
likely be the one from master-0, and this will be shared across all
control plane machines.
It'll be up to the user to set the CPMS to Active
and then the masters will be redeployed in the unique group for all
masters. They will never have a ServerGroup with "clusterID + role" name
because in previous releases we added the AZ name in it.

Author: EmilienM

docs/user/openstack/README.md

@@ -101,7 +101,7 @@ Once you configure the quota for your project, please ensure that the user for t
 
 The default deployment stands up 3 master nodes, which is the minimum amount required for a cluster. For each master node you stand up, you will need 1 instance, and 1 port available in your quota. They should be assigned a flavor with at least 16 GB RAM, 4 vCPUs, and 100 GB Disk (or Root Volume). It is theoretically possible to run with a smaller flavor, but be aware that if it takes too long to stand up services, or certain essential services crash, the installer could time out, leading to a failed install.
 
-The master nodes are placed in a single Server group with "soft anti-affinity" policy by default; the machines will therefore be created on separate hosts when possible.
+The master nodes are placed in a single Server group with "soft anti-affinity" policy by default; the machines will therefore be created on separate hosts when possible. Note that this is also the case when the master nodes are deployed across multiple availability zones that were specified by their failure domain.
 
 ### Worker Nodes
 

pkg/asset/machines/openstack/machines.go

@@ -174,9 +174,17 @@ func generateProvider(clusterID string, platform *openstack.Platform, mpool *ope
 	}
 
 	serverGroupName := clusterID + "-" + role
-	if failureDomain.ComputeAvailabilityZone != "" {
+	// We initially used the AZ name as part of the server group name for the masters
+	// but we realized that it was not useful. Whether or not the AZ is specified, the
+	// masters will be spread across multiple hosts by default by the Nova scheduler
+	// (the policy can be changed via `serverGroupPolicy` in install-config.yaml).
+	// For the workers, we still use the AZ name as part of the server group name
+	// so the user can control the scheduling policy per AZ and change the MachineSets
+	// if needed on a day 2 operation.
+	if role == "worker" && failureDomain.ComputeAvailabilityZone != "" {
 		serverGroupName += "-" + failureDomain.ComputeAvailabilityZone
 	}
+
 	spec := machinev1alpha1.OpenstackProviderSpec{
 		TypeMeta: metav1.TypeMeta{
 			APIVersion: machinev1alpha1.GroupVersion.String(),