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.
Other platforms require at least 100 GB of disk size and we've updated
openshift-docs to reflect that in OpenStack too. Seems like we forgot to
update flavor validation code and docs in the installer. This commit
fixes this.
In 4.12, the default CNI will be OVNKubernetes.
This change will deploy ovnk by default as well
as adjust tests, docs and comments to reflect
the same.
Signed-off-by: Jamo Luhrsen <jluhrsen@gmail.com>
The UPI workflow needs the bootstrap ignition file to be hosted
somewhere. Prior to this patch, the first proposed example used Swift.
However, the example was using commands that are not available in the
openstack client shipped with the recommended operating systems and
repositories.
This patch removes the Swift example and focuses the workflow on using
Glance instead, along the lines of what the IPI installer does. The UPI
docs still mention that any hosting system can be used, including Swift.
This patch adds:
* explanation on how the name of the RHCOS image on Glance must match
the content of inventory.yaml;
* instructions for removing the image after use.
* a scripted unique name for the RHCOS image in Glance, so that the UPI
tests can be run in parallael.
With this patch, the documentation for installing on OpenStack with UPI
is made machine-readable.
Additionally, UPI resources are added to the CI container image.
By default, the cloud provider does not support creation of FIPs
using pre-defined addresses due to a policy that allows this operation
only for admins. This commit updates the documentation with possible
solutions for this issue.
Co-authored-by: Martin André <martin.andre@gmail.com>
Co-authored-by: Max Bridges <50179998+maxwelldb@users.noreply.github.com>
In 4.11, we did the following:
* Remove the dependency on config-drive and support OpenStack Metadata
URL fetching.
* Automate the configuration of VFIO NO IOMMU
* Add support for vhostuser interfaces for DPDK
This patch adds more content for DPDK, with an example of a pod using
hugepages, dedicated CPUs and the DPDK port.
It also add more content for SR-IOV, like how to create a policy & a
pod.
Later, we'll add content for SR-IOV with HW offload.
Before this patch, the migration would sometimes fail with the following
error:
```
cannot delete Pods not managed by ReplicationController, ReplicaSet,
Job, DaemonSet or StatefulSet (use --force to override)
```
- Describe how to deploy cluster onto ovs-dpdk enbled OpenStack
- Describe how to bind the vfi-pci kernel module
- Describe how to configure the host-device network
Co-Authored-By: Adolfo Duarte <adduarte@redhat.com>
Co-Authored-By: Emilien Macchi <emilien@redhat.com>
Co-Authored-By: Stephen Finucane <stephenfin@redhat.com>
