Distribute Control plane machines across user-defined failure domains.
This feature is being release under a TechPreviewNoUpgrade FeatureSet.
Failure domains can be defined in the `controlPlane` machine-pool of
`install-config.yaml` as follows:
```yaml
controlPlane:
name: master
platform:
openstack:
type: ${CONTROL_PLANE_FLAVOR}
failureDomains:
- computeAvailabilityZone: 'nova-1'
storageAvailabilityZone: 'cinder-1'
portTargets:
- id: storage
network:
id: 8db6a48e-375b-4caa-b20b-5b9a7218bfe6
- computeAvailabilityZone: 'nova-2'
storageAvailabilityZone: 'cinder-2'
portTargets:
- id: storage
network:
id: 39a7b82a-a8a4-45a4-ba5a-288569a6edd1
- computeAvailabilityZone: 'nova-3'
storageAvailabilityZone: 'cinder-3'
portTargets:
- id: storage
network:
id: 8e4b4e0d-3865-4a9b-a769-559270271242
```
Each `failureDomains` entry can take an optional
`computeAvailabilityZone` string, an optional `storageAvailabilityZone`
string, and an optional `portTargets` array.
Each `portTargets` entry requires an arbirtary `id`, which must be unique per
`failureDomain`. If `id` is exactly `control-plane`, then that
`portTarget` is used instead of the default primary subnet (or instead
of `machinesSubnet` if defined) as the first machine network.
Each `portTargets` entry takes an optional `network` object and an
optional `fixedIPs` array (not represented in the example).
The `network` object taks an optional `name` string and an optional `id`
string. `name` is ignored if `id` is passed.
Each `fixedIPs` entry takes a `subnet` object which syntax is [defined
in the `machinev1alpha1` spec as
`SubnetFilter`](d170fcdc0f/machine/v1alpha1/types_openstack.go (L230-L281)).
Note that unless an external load balancer is used, `portTargets` with
id `control-plane` must all have one single subnet and must all refer to
the same OpenStack subnet. As a consequence, the result will be similar
as setting a `machinesSubnet`, except that Compute nodes will not
follow.
The validation is no longer necessary now that we stopped using mDNS.
Instead, rely on cluster name validation common to all platforms for
length check and the on-prem cluster name validation for names
containing dots.
This aligns with other on-prem platforms.
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>
Networking resources tagging is a hard requirement for OpenShift on
OpenStack and we should refuse from running the installer when the
underlying OpenStack platform does not support it.
Also, the destroy script may delete unmanaged resources when network
tagging is not available. With this patch, the destroy script will
refuse to work when network tagging is not available.
Fixes Bug 2013877
Co-authored-by: Martin André <m.andre@redhat.com>
Co-authored-by: Pierre Prinetti <pierreprinetti@redhat.com>
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>
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 commit adds a new optional list of strings parameter called
Zones to OpenStack's Root Volume. When it's set, OpenShift will create
instance root volumes in the specified availability zones.
This commit explicitly disables reading auth data from env variables
by setting an invalid EnvPrefix. By doing this, we make sure that the
data from clouds.yaml is enough to authenticate.
After this change we don't have to unset OS_CLOUD env variable explicitly
anymore.
Ref https://issues.redhat.com/browse/OSASINFRA-2152
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>
Despite the fact `externalNetwork` is considered as an
optional parameter, installations fails if it's not specified.
This commit makes this and related parameters truly optional.
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.
- 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
To make the user experience more cohesive, we are adding this feature to
allow users to pass a floating IP to be attached to the ingress port. This
mirrors the way users add the floating ip for the API port.
This commit removes unnecessary ValidValuesFetcher interface and
all related implementations. Now we collect all required data before
the validation and pass cloud info values to the validation functions
after that. It simplifies the architecture and makes these functions
static.
Additionally, all validations that require calls to the OpenStack cloud
were moved from pkg/types/openstack to pkg/asset/installconfig/openstack.
Now, we we validate the platform values, we also modify two of them:
"TrunkSupport" and "OctaviaSupport".
It doesn't make sense, because we set them during generation of the
installconfig and they cannot be defined by the user.
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.
Now we support http(s) schemes only, but for disconnected installs
it's very convenient to specify the local file path to the image file.
This commit adds "file" scheme support, so users can set the location as
"file:///path/to/image".
Currently if we are looking for extensions for Neutron or try to list
services, it might happen, that underlying OpenStack cloud doesn't
support listing either extension or services. This patch is fixing it,
and assumption is, that trunk support is disabled in a case of
inability of listing Neutron extensions, and/or octavia support is
disabled in case of inability of listing services, instead of aborting
installation.
For IPv6 dual-stack support we need to support multiple
machine networks in order to register both an IPv4 machine prefix
and an IPv6 prefix (Azure in particular requires the user to define
a prefix which could conflict with the service or pod networks).
Update core types and validation to react to the change from a
single field to an array. Update the validation messages to be
consistent with the field the user would see (a "machine network")
instead of using "subnets" or "machineCIDR".
