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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 the forum is a good place for that they have a mailing list and we also have Fedora core OS on freenode
