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`.
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
With this change, Compute nodes within each MachineSet are automatically
created in a Server group, with a default policy of
"soft-anti-affinity".
With this change, a "serverGroupPolicy" can be set in install-config, on
the worker MachinePool and/or in the platform default.
Implements OSASINFRA-2570
Co-Authored-By: Matthew Booth <mbooth@redhat.com>
In 4.9 we introduce support for LoadBalancer services. This means that
user might need to tweak the cloud provider options to match their
OpenStack cluster configuration. This commit adds documentation on how
to do it before and after the installation.
Prior to this change, the Control plane nodes are created in a server
group with the hardcoded policy "soft-anti-affinity".
This change adds a new configuration knob in the OpenStack-specific
MachinePool configuration of `install-config.yaml`.
The new property `controlPlane.platform.openstack.serverGroupPolicy`
defines the policy that will be applied to the Control Plane server
group.
Acceptable values are:
* `affinity`
* `anti-affinity`
* `soft-affinity`
* `soft-anti-affinity`
Defaults to `soft-anti-affinity`, to match the previous hardcoded
behaviour.
Validation will fail if the property is set on the Compute MachinePool.
This implements part of the plan from:
https://github.com/openshift/os/issues/477
When we originally added the pinned RHCOS metadata `rhcos.json`
to the installer, we also changed the coreos-assembler `meta.json`
format into an arbitrary new format in the name of some cleanups.
In retrospect, this was a big mistake because we now have two
formats.
Then Fedora CoreOS appeared and added streams JSON as a public API.
We decided to unify on streams metadata; there's now a published
Go library for it: https://github.com/coreos/stream-metadata-go
Among other benefits, it is a single file that supports multiple
architectures.
UPI installs should now use stream metadata, particularly
to find public cloud images. This is exposed via a new
`openshift-install coreos print-stream-json` command.
This is an important preparatory step for exposing this via
`oc` as well as having something in the cluster update to
it.
HOWEVER as a (really hopefully temporary) hack, we *duplicate*
the metadata so that IPI installs use the new stream format,
and UPI CI jobs can still use the old format (with different RHCOS versions).
We will port the UPI docs and CI jobs after this merges.
Co-authored-by: Matthew Staebler <staebler@redhat.com>
Due to the addition of the PrimarySubnets variable in the providerSpec
we wanted to ensure that users knew it existed and of its pitfalls.
Fixes: OSASINFRA-2088
The option exists for a long time, but it is not documented for
OpenStack. This commit fixes it.
Also it changes ip -> IP in some places to make it consistent
across the document.
ClusterOSImageProperties is a list properties to be added
to the installer-uploaded ClusterOSImage in Glance.
The default is to not set any properties.
Co-Authored-By: Martin André <m.andre@redhat.com>
Following suit with AWS, OpenStack is adding support for custom AZs
for installer machine pools. Users can pass a list of zones to use
and the nodes in that machine pool will be spread across them.
The user interface for floating IPs has been changed such that
the ingress and api floating ips can no longer be passed when
the external network is unset. These validations check that this
usage is respected, while also checking the the floating IPs passed
by the user are valid and available.
- Removes floating ip binding from bootstrap server
if external network is not used
- Added documentation for optional externalNetwork
- Modifies gather to handle when floating ips are not used
It may not be possible to set a router to the external network, or may
not be necessary, depending on how the customer chooses to route their traffic.
Since it is very hard to contextually deduce what external routing
scheme the customer wants to set up, it is preferrable to just not
attempt to automate anything for them, and let them customize it themselves.
Users want to re-use and customize their networking infrastructure during IPI
installs, so to enable them, we are allowing them to pass custom subnets to the
installer.
