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>
Documentation on how to manually set the Server group in the MachineSet
manifests at install-time is no longer necessary, since the introduction
of the `serverGroupPolicy` property in the OpenStack platform section of
install-config's machine-pools.
Co-authored-by: Max Bridges <50179998+maxwelldb@users.noreply.github.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>
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 use case requires a unique usage pattern in comparison to what the
customer may be use to, so we chose to document it in its entirety to
avoid any confusion down the line.
This patch adds a documented known issue where we explain that we can't
edit a machine spec or it'll lead to problems like the servers being
removed.
We also give a tested resolution procedure.
More info: https://access.redhat.com/solutions/5998451
We're validating the cluster name size and there's no need to document
this as a known issue, especially with mDNS going away.
We might loosen the cluster name length restriction in the future.
Add a note that if we deploy a cluster in an OpenStack AZ, it's
suggested to use Cinder backend if the service is available in this AZ,
since Cinder is topology aware.
Swift isn't deployed in AZs usually, so traffic would have to go
through the link between sites, which isn't optimal in real world.
Signed-off-by: Emilien Macchi <emilien@redhat.com>
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>
This is a first iteration of documenting how to deploy OCP clusters on
provider networks and all the gotchas.
Signed-off-by: Emilien Macchi <emilien@redhat.com>
Installations with Kuryr can timeout because of
recent changes on the way the nodes' subnet is retrieved.
This commit adds a section to the know issues describing
why the issue occour and how to avoid it.
With 9314e6dc5823690a08109acd26583c517912f55d, the Installer reads the
`clouds.yaml` `cacert` file to connect to the OpenStack API. It is
therefore no longer necessary to add the certificate to the system
trust.
