History

It’s a new year and it has been 5 years since the last time I updated this blog post series. This time I’m updating to Fedora 41 and also bringing forward a lot of changes I’ve made over the last 5 years.

As mentioned previously for now I’m using Fedora Silverblue on my laptop systems and continuing with a BTRFS+snapper setup for my desktop. This series describes the BTRFS+snapper setup.

In the past I have documented this setup and all the steps I took in detail for Fedora 22 (part1 and part2), 24, 25, 27, 29 and 31. This is a condensed continuation of those posts for Fedora 41, but there are a few changes I’ve made.

Introduction

I recently did a blog post series. showing how to get started with OpenShift OKD on Fedora CoreOS for DigitalOcean. For that series I wrote a script to do most of the heavy lifting because DigitalOcean isn’t a native supported platform by the OpenShift installer.

Today I’ll show off how to get started in GCP, which is supported natively by the OpenShift installer. This makes it much easier to get started because most of the heavy lifting (including infrastructure bringup) is done by the installer itself.

NOTE: The fourth post of this series is available here.

This blog post is the fifth in a series that illustrates how to set up an OpenShift OKD cluster on DigitalOcean.

Back on August 17th I highlighted this blog post series with a presentation and demo for the OKD working group’s Demo Marathon.

The video is posted on YouTube and also available below. If you’re interested take some time and watch the whole process work and see a cluster up and running at the end.

Introduction

NOTE: The third post of this series is available here.

This blog post is the fourth in a series that illustrates how to set up an OpenShift OKD cluster on DigitalOcean. The third post in the series covered further configuration of a cluster once it’s already up and running. At this point you should have a cluster up and running and configured with custom TLS certificates and user login’s outsourced to some other identity management service.

Introduction

NOTE: The second post of this series is available here.

This blog post is the third in a series that illustrates how to set up an OpenShift OKD cluster on DigitalOcean. The second post in the series covered the automated deployment and teardown of a cluster using the digitalocean-okd-install script. At this point you should have a cluster up and running and ready to be further customized.

Set Up Custom TLS Certificates

In the first post in this series we mentioned that you may want to have valid certificates for your cluster. For this example we used certbot to talk with Let's Encrypt to get us some certificates for use with our cluster. Assuming the files are in the letsencrypt/ directory we can add the certificates to our cluster like so:

Introduction

NOTE: The first post of this series is available here.

This blog post is the second in a series that illustrates how to set up an OpenShift OKD cluster on DigitalOcean. The first post in the series covered some background information and pre-requisites needed for deploying a cluster. At this point you should have chosen the domain for your cluster, set up your registrar to point to DigitalOcean nameservers, installed all necessary software (doctl, openshift-install, oc, aws cli, etc..), and configured appropriate credentials in your environment (DIGITALOCEAN_ACCESS_TOKEN, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY).

Introduction

This blog post is the first in a series that will illustrate how to set up an OpenShift OKD cluster on DigitalOcean using the bare metal install documentation (user provisioned infrastructure). OKD has tight integrations with the Operating System and uses Fedora CoreOS as a platform for driving the underlying infrastructure, thus we’ll be deploying on top of Fedora CoreOS images inside of DigitalOcean.

The documentation for OKD is pretty comprehensive, but there is nothing like having a guide to help fill in some of the gaps and show an example of it working with real world values. This series aims to do just that.

Introduction

With Fedora CoreOS we currently have two ways to do a bare metal install and get our disk image onto the spinning rust of a “non-cloud” server. You can use coreos.inst* kernel arguments to automate the install, or you can boot the Live ISO and get a bash prompt where you can then run coreos-installer directly after doing whatever hardware/network discovery that is necessary. This means you either do a simple automated install where you provide all of the information up front or you are stuck doing something interactive. However, because we use a Live ISO that boots full Fedora CoreOS there is a third option.

Introduction

NetworkManager allows connections to be defined in a configuration file known as a keyfile , which is a simple .ini-style formatted file with different key=value pairs. In Fedora CoreOS we’ve elected to use NetworkManager with keyfiles as the way to configure networking. In case you have a standard networking environment with NICs requesting DHCP then you probably won’t need to configure networking. However, if you’d like to have a static networking config or if you’d like to do something more complicated (like configure network teaming for a few interfaces) then you’ll need to create a keyfile that NetworkManager will then use to configure the interfaces on the machine.

Introduction

For some time now with virt-install (developed under virt-manager) you have been able to specify a kernel and initial ramdisk to start a VM with. The only problem is that the VM will always start with that kernel/initrd (unless you change the definition manually). If you are rapidly testing operating system installations this can be problematic.

On the one hand, providing the kernel/initrd allows one to automate the install process from a Linux terminal, or even a script, by specifying the kernel/initrd and also the kernel command line options. However, it only gives us half the picture, because you’d then have to hand edit the libvirt definition of the machine to see if the installed machine was viable, OR you’d be lazy and just throw away the installed machine and assume it was good because the installation process finished without error; BAD.