The Registry is managed by the Image Registry Operator, deployed to the openshift-image-registry project.
As of this writing (installer 0.12.0), the deployment follows the steps outlined in the manifest directory:
When creating an OCP cluster using openshift-installer that fails before the metadata.json file is created, cleaning up can be difficult because it doesn't know what needs to be removed. Fortunately, there is a workaround:
Configure AWS CLI
This assumes you have configured the AWS CLI using your credentials. If you have not done this, follow the instructions
Retrieve the cluster ID
Prosody is an XMPP server. My instance is currently hosted on a DigitalOcean VM, running in the smallest droplet avaialble, which is still far more resources than a server with just a few users needs.
At the end of these steps we will have a Prosody server which is isolated (no server-to-server comms), requires an administrator to create new user accounts, is using valid SSL certs issued by Let's Encrypt, and capable of handling file transfers up to 10MiB in size via the https upload service. This was written with CentOS 7.6.
Before beginning, make sure you have DNS entries for the following:
OpenShift 4.x relies heavily upon operators for automating all aspects of the services. Discovering which operator controls which service can be difficult and confusing, but there are some steps we can take to help make the process easier and make educated guesses.
This document focuses on OpenShift core services, not add-on operators. While much, if not all, of the information still applys to those types of operators, they are much easier to see, manage, and inflect due to their nature. Be sure to see and read about the Operator Framework for the most up to date information about them.
Some prerequesites:
| apiVersion: kubevirt.io/v1alpha3 | |
| kind: VirtualMachine | |
| metadata: | |
| annotations: | |
| kubevirt.io/latest-observed-api-version: v1alpha3 | |
| kubevirt.io/storage-observed-api-version: v1alpha3 | |
| name.os.template.kubevirt.io/silverblue32: Fedora 31 or higher | |
| name: fedora | |
| labels: | |
| app: fedora |
| [global] | |
| rw=write | |
| ioengine=sync | |
| fdatasync=1 | |
| [etcdtest] | |
| directory=. | |
| size=22m | |
| bs=2300 | |
| write_bw_log=etcdtest |
Refer to the (now deprecated) project page here for additional details
# create the namespace
cat << EOF | oc apply -f -
kind: Namespace
apiVersion: v1
metadata:
name: nfs-provisionerThis page represents a collection of fio performance tests, tuned for a Kubernetes etcd workload per this blog post, against various storage and platforms.
The goal is to execute the below fio command on as many different places as possible to gauge relative performance.
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytestThese tests are completely unscientific and only serve to provide a sampling for anecdotal comparisons.
This gist provides some additional information referenced in the Ask an OpenShift Admin livestream on January 12th, 2022.
Triggering an update to the cluster is done the same way, whether you're doing an update between z-streams (e.g. 4.9.8 -> 4.9.13) or an upgrade between y-releases (e.g. 4.8.z -> 4.9.z). There are three primary options:
Use the webconsole This is pretty straightforward, browse to the Administration panel, then click the update button. If you're upgrading between y-releases, you may need to change the release stream.
Use the CLI
This, loosely, documents installing RHV as an all-in-one server. This is not supported and has some flakiness, particularly for updates. Additionally, because it's a lab, no "real" storage was used.
The Server
The physical server used for this has 8 core, 32GB RAM, and a 512GB NVMe drive connected to the network using a single 1 GbE link. You'll need at least 200GiB of storage to comfortably host more than a couple of VMs.