When following this guide using RHEL or older Fedora there is an issue
with the openstack.cloud with latest version (2.0.0) as it will need
openstacksdk in version 1.0 or higher, which is unavailable in mentioned
Linux distribution.
In 4.15 Kuryr is no longer a supported NetworkType, following its
deprecation in 4.12. This commit removes mentions of Kuryr from the
documentation and code, but also adds validation to prevent
installations from being executed when `networkType` is set to `Kuryr`.
Compact clusters have been supported for a while in IPI.
To also allow compact clusters on UPI, the security group rules
for UPI should be adapted enabling the same ingress traffic
that is enabled for workers.
The `MachinesSubnet` field has been reshaped as `controlPlanePort`,
this commit updates the docs to ensure `controlPlanePort` is used.
Also, this commit adds dual-stack documentation.
When a machine is created with a compute availability zone (defined via `mpool.zones`) and a storage root volume (defined as `mpool.rootVolume`) and that `rootVolume` has no specified `zones`, CAPO will use the compute AZ for the volume AZ.
This can be problematic if the AZ doesn't exist in Cinder.
Source:
9d183bd479/pkg/cloud/services/compute/instance.go (L439-L442)
```golang
func (s *Service) getOrCreateRootVolume(eventObject runtime.Object, instanceSpec *InstanceSpec, imageID string) (*volumes.Volume, error) {
(...)
availabilityZone := instanceSpec.FailureDomain
if rootVolume.AvailabilityZone != "" {
availabilityZone = rootVolume.AvailabilityZone
}
(...)
```
If a compute AZ is provided alongside with a root volume, we now require
the root volume to have an AZ, so we force the user to make a choice on
which AZ the root volume is deployed on.
We are also enforcing it via CEL validation in OpenShift API.
* Do nothing - at the risk of hitting this situation: a failure domain with a Compute AZ and a root volume with no AZ, CAPO using the compute AZ to create the volume but that AZ doesn't exist in Cinder, leading into Machine creation errors.
* Only do a validation in the CPMS - which will require CPMS manual
edits from the user.
* Change logic in CAPO wrt how root volume AZ is picked - unlikely to happen
When attaching a manila network by editing a machinset, you probably
want to disable allowed address pairs. Document this.
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
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.
Fix a syntax error in the validation script. Before this change, the
script would not detect, and thus error, on an endpoint with a schema
that is not HTTP and not HTTPS.
Before this change the validation steps, and the script, assumed that
`internal` and `admin` OpenStack endpoints were always reachable. With
this change, the manual steps and the script are amended to only check
the validity of HTTPS certificates on the `public` endpoints of the
OpenStack catalog.
Provide manual instructions to check the HTTPS certificates of the
OpenStack endpoints for systems where the required tools for the
provided script aren't available.
Our indicated supported version was incorrect. Rather than having to
remember to update it for each new OSP version, simply remove this
snippet.
The LB FIP is now called the API FIP.
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Before this documentation patch, the known issue about
soft-anti-affinity had several issues:
* it was in the UPI section, when it is not a UPI-specific issue
* it mentioned Control plane scale-out, when OCP only supports exactly 3 masters
* it is now possible to set strict anti-affinity from the
install-config.yaml, and that should be the recommended solution when
VM distribution across hosts is required.
