Red Hat OpenShift OKD Working Group, 13 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Fedora CoreOS Introduction - Dusty Mabe (Red Hat)

Description

Fedora CoreOS Introduction
Dusty Mabe (Red Hat)
July 13 2020
exerpted from OpenShift Commons Briefing FCOS AMA session
does not include demo

A

My name is dusty: mabe I work for Red, Hat and I'm here to talk about Fedora core West today. So briefly, I'm gonna talk about what is Fedora core OS I'm gonna talk about some of the features of Fedora core OS, how it relates to rel core OS, and also how does it relate to ok d? Ok, Fedora core OS. What is it it's an emerging Fedora edition. It came from the merging of two communities: one was core OS inks container linux, community and also project Atomics atomic host community.

A

It incorporates the container Linux philosophy or what we've been referring to as the container Linux philosophy, the provisioning sac and the cob native expertise of container Linux, and it also incorporates atomic hosts Fedora foundation. The update stack and the enhanced security with SC Linux.

A

So first I want to talk a little bit more about the philosophy behind container Linux because it really has driven what we've done with Fedora core OS. So, first off container, linux focus primarily on automatic updates, which means that the administrator by default has no interaction with the system in order to keep the system up-to-date and the goal there is that staying up-to-date in a default. Automated manner means that security fixes get automatically applied and your systems stay more secure, so more secure by default.

A

Container Linux also had all nodes start from approximately the same starting point and they used ignition in order to achieve this goal, so you would use ignition to provision a node wherever it started, whether it be on bare metal or on cloud, and they all essentially start from the same starting point.

A

Container Linux also focused on immutable infrastructure. So, for example, if you need a change, you're encouraged to update your configuration and reprovision this kind of guarantees that you know your changes, make it back into your configuration and it's tested because guess what you've tested that for visioning when you brought up a new node, also user software runs in containers, which means that applications don't depend on the host and they the host updates, are more reliable. When you have automatic updates, you need them to be reliable.

A

So now we're going to talk about Fedora, core OS and you're, going to hear a lot about that. Those features that I just mentioned, or the philosophy I just mentioned the first one being automatic updates, so Fedora core OS features automatic updates by defaults, and if you have automatic updates, you need them to be reliable. How do we achieve this goal? So we achieve this goal by having extensive tests in automated CI pipelines.

A

We also have several update streams, which I'll touch on in a minute that allow users to preview. What's coming, users run the various streams so that they can know when changes are coming, that they need to either address or report issues, for we also have managed upgrade rollouts so upgrades. You know upgrade windows happen over several days.

A

If people choose early in the rollout window, they report them, and we can, you know, address the issue, stop the rollout window if we need to and then of course things will go wrong at some point for when things go wrong, we have our pmos tree roller, which can be used to go back to the previous version and in the future we plan to have some sort of automated rollback functionality, where a user can specify a if this particular health check doesn't pass.

A

I want you to automatically go back to the previous version before this update. That's a future feature, not something we have just yet. Okay. I mentioned multiple update streams. Right now we have three update streams which we offer that have automated updates. One is next that stream is focused more on experimental features or Fedora major release, rebase --is. So, for example, when we switch to see routes b2 right now, we're on Siegrist be one in Fedora core OS.

A

When we switch stuff see groups v2 will land that in the next stream first, uh it will have some soak time there. Hopefully, people report any issues we get them fixed and then eventually they'll go into testing and stable. Also, for example, when we switch from Fedora 32 to fedora 33. That will happen in next first. So it's an opportunity for us to I. You know put those breaking changes that are going to happen or possibly breaking changes that are gonna happen in there and get them tested.

A

Okay, so testing is basically a preview of what's coming to stable, it's a point in time, snapshot of Fedora, stable RPM content, and that is going to go directly into stable in two weeks. If we don't find issues so the goals of having these update streams are to publish new releases into update streams every two weeks and also find issues and get them fixed, so they don't hit the stable stream.

A

The Fedora core, OS release promotion. I touched on this. Briefly. We have a version number that basically incorporates the Fedora major the date at which content was snapshotted from Fedora, stable, repos and then also a number that indicates which released stream we're on. So we have. We have three release streams. We have testing stable and next, and that number corresponds to a release stream, and then we have a revision. So if we do an ad hoc fix to a content set, we will bump that revision number and pre-release so for the young repositories.

A

If this represents the yum repository moving in time, we will snapshot that on, in this case the third or the 23rd of March. That becomes the testing stream. We do a testing stream release and then hopefully we don't find any issues. Two weeks later, that gets promoted to stable and people in the stable stream get that content.

A

Ok. The next feature is automated provisioning. The Fedora core OS uses ignition to automate provisioning. Just like container Linux did any logic for machine lifetime is encoded in the config, so it's very easy to automatically reprovision nodes.

A

An example of this is earlier this year, I have a node sitting on my desk in the office that runs for the work or OS, and it also happens to be a an IRC client server setup that I have yet I lost power to it at some point and it didn't turn itself back on, so I wasn't able to get to it and I also wasn't able to get into the office because of Kovan.

A

So I took the configs that I used to bring up that server and I just spun up of the at home and I was back up and running in ten minutes. So that's an example of you know, because everything is is baked into these ignition configs. It's really easy to get a new node up and running in the same profile as the one that you had and then because we're using ignition. We have the same starting point: whether we're on bare metal or cloud. We use the approximately the same image everywhere.

A

So we because we can use the ignition everywhere as opposed to kickstart, for bare metal and clouding it from cloud it kind of unifies. The whole experience our case, so the details of ignition ignition is a declarative, JSON document, it's machine friendly, so not very user friendly. Unless you like to read JSON, it runs exactly once during the MF s stage on boot. It can write filesystem, two units, users, groups, partition disks, etc.

A

The key point here is: if provisioning fails, the boot fails. So you don't end up with a half provision system, sometimes with cloud in it. You could have part of it succeed and part of it not succeed, and then you've got an application up. That's half running with ignition. You know it's good, because you know the machine didn't provision correctly, but it also can be bad because it's hard to debug in the init run off s. So there's good and bad there, but we like it overall, particularly ignition, is not very human friendly.

A

So we have a tool called the Fedora core OS config transpiler. That is a lot more human friendly, it's written in yamo, and it also has some what we call sugar on top that will automatically write out some of the more tedious parts of ignition for you.

A

So the next feature I'd like to talk about is basically cloud native and container focus, so software runs in containers and users have two options: they have pod man or movi engine, which is also known as docker those two container runtimes. If you're kind of coming from container Linux, you still have docker.

A

If you want to use that or if you want to try out pod man, that's there for you, it's ready for cluster deployments, so you can spin up a hundred nodes and have them join a cluster, because the ignition configs are used to automate the cluster join it kind of take. It takes care of everything for you and then you can spin down nodes and spend them up again as you need. So that's kind of more of the cloud native piece of it.

A

It's also also offered on a plethora of clouds and for platforms, so we're trying to be on any major cloud platform, and you know we're adding new ones every day, OS, versioning and security. So this is one that I'll dig into a little bit.

A

Fedora core OS uses rpm OS tree technology, I like to describe it as like and get for your operating system, so we have, for example, a particular version of Fedora core OS, which is kind of like a tag. You have a version and also a git commit or sorry of an OS tree commit hash, and this single identifier tells you all the software that's in a particular release. It tells you all.

A

The RPM content tells you all the config default settings that are delivered, and that is important when you are trying to report issues or share information. So as a user, you can report an issue and say: hey I'm, on this specific commit of Fedora, core OS and I run these steps and I see this problem and that's really powerful because it uses our pmos tree. It also has read-only file system now which prevents accidental OS corruption.

A

So if you happen to RM RF on the wrong directory- and it also prevents some- you know- Novus attacks from modifying the system- we also have sa Linux enforcing by default, which prevents compromised apps from gaining further access, which is not something that container Linux had ok. So what's in the OS, we have the latest Fedora based components built from rpms. We have hardware support, so hopefully anything that Fedora supports. We can support footed or four OS. We have basic administration tools, we have container engines and not much else, so we don't have Python.

A

The goal here is that we encourage users to run their applications in containers and not run things directly on the host. That makes our updates more reliable. We don't want to update the host and break your application.

A

Ok, so, coming soon we have more cloud platforms that we're adding. We also are trying to get support for multi arch we've got more. You know human friendly helper functions that we want to add to Fedora core OS config transpiler. We want to make our package layering more reliable in cases that might need that we want to have more flesh, improved documentation and then also tighter integrations with okd.

A

When you talk about fedora and rel core OS, you want to know what's the difference. So at a high level, the biggest difference is obviously based on rel package set versus based on a Fedora package set, but the probably the larger thing is Rho dot. Red Hat core OS is only designed or meant to be used directly with openshift itself and not meant to be used standalone. So the updates for Red Hat, core OS are delivered and controlled by the cluster itself and not independently of the cluster.

A

What's the dork or OS, you can use it either standalone or you can use it as part of a cluster so, for example, with ot, ok D in the standalone case, you get the updates directly from Fedora core OS is real servers in the case of okd. You get the updates similar to how Red Hat chorus gets its updates from containers in the registry. So you can use Fedora core OS standalone with other quests or orchestration technologies or with okd.

A

Ok, specifically, ok, D is installable with ok, DS installer, so the same one that OCP uses OpenShift install the cluster controls. The OS upgrades as I mentioned a minute ago, upgrades are provided as machine OS content containers and then the cluster can manage and bring up new machines automatically, which I think is the coolest point there right at the end. If you want to go just grab the door core OS or view our releases, we have the top level gift fedora, dr. org, slash core OS for any issues or kind of design. Discussion related stuff.

A

We usually open tickets in our Fedora core OS tracker. So that's github comm, slash core OS, slash Fedora core OS tracker, so you can open an issue there and that's where we can kind of dig into the details of the hardware, RAID controller support and we also have a forum if you have kind of like a more of a user related question related to you, know: I can't. How do you set a password or things like that on?

A

The forum is a good place for that they have a mailing list and we also have Fedora core OS on freenode.