Modding the Immutable – how to extend Flatcar, an immutable image-based OS
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 287 | |
| Autor | ||
| Lizenz | CC-Namensnennung 2.0 Belgien: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/57011 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
FOSDEM 2022182 / 287
2
4
6
8
12
17
21
23
31
35
37
41
44
45
46
47
50
62
65
66
67
68
71
73
81
84
85
86
90
92
94
100
102
105
111
114
115
116
117
118
121
122
124
127
131
133
135
137
139
140
141
142
145
149
150
156
164
165
167
169
170
171
172
174
176
178
180
183
184
189
190
192
194
198
205
206
207
208
210
218
220
224
225
229
230
232
235
236
238
239
240
242
243
244
245
246
249
250
253
260
262
264
267
273
274
277
282
283
287
00:00
DistributionenraumRechenschieberNetzbetriebssystemDiagrammBesprechung/Interview
00:29
SpezialrechnerSignifikanztestGrenzschichtablösungPhysikalisches SystemQuellcodeDistributionenraumDatenmanagementCase-ModdingPartitionsfunktionBinärdatenJensen-MaßSoftware Development KitServerLaufzeitfehlerModul <Datentyp>Kernel <Informatik>Overlay-NetzBefehl <Informatik>SkriptspracheSoftwarewartungDatenmanagementE-MailTwitter <Softwareplattform>NetzbetriebssystemMathematische LogikOpen SourcePhysikalisches SystemLesen <Datenverarbeitung>Rechter WinkelSignifikanztestVerzeichnisdienstFunktion <Mathematik>Lokales MinimumLaufzeitfehlerFokalpunktInstantiierungBetafunktionKette <Mathematik>StrömungsrichtungEndliche ModelltheorieGebäude <Mathematik>BinärdatenGrenzschichtablösungPunktSichtenkonzeptKartesische KoordinatenGleitendes MittelDatensatzNichtlinearer OperatorGrundsätze ordnungsmäßiger DatenverarbeitungDienst <Informatik>Konfiguration <Informatik>Befehl <Informatik>Zentrische StreckungZusammenhängender GraphMereologieBitGraphfärbungPartitionsfunktionTreiber <Programm>Wurzel <Mathematik>BereichsschätzungTermQuellcodeAggregatzustandProjektive EbeneDokumentenserverSoftwareentwicklerBrennen <Datenverarbeitung>SkriptsprachePlastikkarteZentralisatorComputersicherheitSchnittmengeDatenverwaltungProgrammbibliothekStabilitätstheorie <Logik>BimodulProgrammfehlerKrümmungsmaßOrdinalzahlUmwandlungsenthalpieDefaultDisjunktive NormalformSampler <Musikinstrument>Overlay-NetzKernel <Informatik>Offene MengeBeanspruchungCachingComputeranimation
06:11
Auflösung <Mathematik>DeltafunktionW3C-StandardKlon <Mathematik>BimodulKlon <Mathematik>Endliche ModelltheorieKategorie <Mathematik>VersionsverwaltungDivergente ReiheBimodulComputeranimation
06:50
VersionsverwaltungStereometrieSpezialrechnerSignifikanztestBinärdatenJensen-MaßNetzbetriebssystemBetafunktionSoftwareentwicklerMultiplikationsoperatorMathematikClientPunktVerzweigendes ProgrammVersionsverwaltungGruppenoperationNichtlinearer OperatorInverser LimesSampler <Musikinstrument>Konfiguration <Informatik>Prozess <Informatik>EnergiedichteEinfügungsdämpfungQuick-SortStabilitätstheorie <Logik>AutorisierungOffice-PaketComputeranimation
08:52
Objekt <Kategorie>DistributionenraumJensen-MaßBetafunktionMIDI <Musikelektronik>MedianwertNormierter RaumVerzweigendes ProgrammQuick-SortWeb-SeiteTopologieJensen-MaßComputeranimationXML
09:19
KrümmungsmaßSpezialrechnerGEDCOMJensen-MaßOrtsoperatorSoftware Development KitSkriptspracheVersionsverwaltungKrümmungsmaßJensen-MaßSchnitt <Mathematik>Elektronische PublikationVerzweigendes ProgrammWrapper <Programmierung>QuellcodePhysikalisches SystemMultiplikationsoperatorVideokonferenzExogene VariableZahlenbereichWort <Informatik>Programm/Quellcode
10:25
SpezialrechnerMathematikNetzbetriebssystemTermVirtuelle MaschineAggregatzustandGesetz <Physik>VersionsverwaltungStellenringsinc-FunktionComputeranimation
11:00
GEDCOMBinärdatenSinusfunktionOvalGebäude <Mathematik>GarbentheorieAttributierte GrammatikSoftwareentwicklerGruppenoperationSkriptspracheWrapper <Programmierung>RoutingBinärdatenNetzbetriebssystemPhysikalischer EffektMathematikSchnittmengeRechter WinkelCompilerKomplex <Algebra>ComputeranimationProgramm/Quellcode
12:01
SpezialrechnerMultiplikationsoperatorMathematikSkriptspracheWellenpaketComputervirusNetzbetriebssystemBinärdatenRoutingCachingCompilerComputeranimation
12:42
Attributierte GrammatikSpezialrechnerInformationsmanagementBinärdatenWrapper <Programmierung>SkriptspracheNetzbetriebssystemProzess <Informatik>BinärdatenComputeranimationProgramm/Quellcode
13:07
SpezialrechnerKonfigurationsraumTotal <Mathematik>Software Development KitJensen-MaßProdukt <Mathematik>InformationMagnetbandlaufwerkKernel <Informatik>TermVerzeichnisdienstProdukt <Mathematik>Funktion <Mathematik>BinärdatenGebäude <Mathematik>Programm/Quellcode
13:37
Nabel <Mathematik>Konfiguration <Informatik>Elektronische PublikationSpezialrechnerGeradeBootenProdukt <Mathematik>VersionsverwaltungSchlüsselverwaltungHill-DifferentialgleichungSkriptspracheAttributierte GrammatikGarbentheorieWhiteboardOverlay-NetzPartitionsfunktionBinärdatenW3C-StandardGEDCOMJensen-MaßSkriptspracheTermBinärbildWiederkehrender ZustandWrapper <Programmierung>BootenMereologiePhysikalisches SystemTopologieVersionsverwaltungTexteditorZweiProdukt <Mathematik>DefaultVirtuelle MaschineWurzel <Mathematik>NetzbetriebssystemFunktion <Mathematik>Nabel <Mathematik>GenerizitätVerzeichnisdienstProgramm/QuellcodeComputeranimation
16:11
SpezialrechnerQuellcodeVarietät <Mathematik>TouchscreenSkriptspracheNichtlinearer OperatorZahlenbereichRepository <Informatik>StellenringMathematikGebäude <Mathematik>NetzbetriebssystemVarietät <Mathematik>Wrapper <Programmierung>TouchscreenWurzel <Mathematik>BimodulVerkehrsinformationEndliche ModelltheorieBenutzerschnittstellenverwaltungssystemPhysikalisches SystemStabilitätstheorie <Logik>UmwandlungsenthalpieKette <Mathematik>GruppenoperationComputeranimation
18:38
Objekt <Kategorie>TouchscreenVerzeichnisdienstRepository <Informatik>Computeranimation
19:06
Elektronische PublikationKonfiguration <Informatik>DistributionenraumLie-GruppeFiletransferprotokollMetadatenTouchscreenRepository <Informatik>PunktStabilitätstheorie <Logik>Overlay-NetzMultiplikationsoperatorKrümmungsmaßProgramm/Quellcode
20:01
LimesmengeGebäude <Mathematik>SpeicherabzugWeb-SeiteSchnitt <Mathematik>BestimmtheitsmaßInformationTouchscreenNetzbetriebssystemServerComputeranimation
20:37
FiletransferprotokollKonfiguration <Informatik>Elektronische PublikationGEDCOMTouchscreenPhysikalisches SystemGammafunktionE-MailPatch <Software>Overlay-NetzTouchscreenMereologieNetzbetriebssystemComputeranimation
21:11
TouchscreenFiletransferprotokollKonfiguration <Informatik>Elektronische PublikationInnerer PunktKlon <Mathematik>Objekt <Kategorie>AbzählenW3C-StandardGewicht <Ausgleichsrechnung>SpezialrechnerInverser LimesCompilerKlon <Mathematik>SkriptspracheRoutingTouchscreenMathematikNetzbetriebssystemSampler <Musikinstrument>PunktComputeranimationProgramm/QuellcodeJSON
21:45
CADFunktion <Mathematik>Codierung <Programmierung>KonfigurationsraumQuellcodeTouchscreenWeb-SeiteSpezialrechnerInformationVerzeichnisdienstLaufzeitfehlerDreiDateiverwaltungMessage-PassingVersionsverwaltungDienst <Informatik>Jensen-MaßSocketPhysikalisches SystemPunktTouchscreenMathematikRoutingCompilerCachingProgramm/Quellcode
22:22
Konfiguration <Informatik>Elektronische PublikationNetzbetriebssystemTouchscreenMailing-ListeElektronische PublikationComputeranimation
22:47
SystemprogrammGerichtete MengeMetadatenElektronischer FingerabdruckElektronische PublikationMailing-ListeNetzbetriebssystemMathematikSkriptspracheOrdnung <Mathematik>Schnitt <Mathematik>TouchscreenZeichenvorratComputeranimation
23:17
VersionsverwaltungJensen-MaßDienst <Informatik>InformationGarbentheorieBEEPPhysikalisches SystemQuellcodeW3C-StandardSpezialrechnerBimodulMathematikOrdnung <Mathematik>SkriptspracheWurzel <Mathematik>VersionsverwaltungMultiplikationsoperatorLie-GruppeWeb-SeiteProgramm/QuellcodeJSON
24:07
BinärdatenSoftwareentwicklerSpezialrechnerW3C-StandardInklusion <Mathematik>QuellcodeDateiverwaltungGarbentheorieInformationGebäude <Mathematik>VerzeichnisdienstBootenSkriptspracheMultiplikationsoperatorResultanteRechenwerkProgramm/QuellcodeComputeranimation
25:24
W3C-StandardKontrollstrukturTouchscreenGemeinsamer SpeicherFunktion <Mathematik>NetzbetriebssystemComputeranimation
25:55
SpezialrechnerSignifikanztestSoftware Development KitSuite <Programmpaket>Mathieu-DifferentialgleichungKrümmungsmaßPlastikkarteNetzbetriebssystemMathematikDatensatzSignifikanztestSuite <Programmpaket>Statistischer TestSpannweite <Stochastik>PufferüberlaufDienst <Informatik>Computeranimation
27:00
PolstelleJensen-MaßKrümmungsmaßResultanteMereologieInhalt <Mathematik>VerzeichnisdienstFunktion <Mathematik>Dienst <Informatik>ZahlenbereichSignifikanztestStatistischer TestElektronische PublikationNetzbetriebssystemSchaltwerkPunktInstantiierungServerDateiformatTermWarteschlangeProzess <Informatik>Programm/QuellcodeJSON
28:34
Elektronische PublikationKonfiguration <Informatik>Witt-AlgebraSpeicherabzugTouchscreenE-MailPatch <Software>Prozess <Informatik>RuhmasseVerzeichnisdienstMathematikSpeicherabzugElektronische PublikationDifferenteDifferenz <Mathematik>TouchscreenOverlay-NetzPatch <Software>Projektive EbeneInstantiierungVerschlingungMetrisches SystemComputeranimation
29:20
SystemaufrufCOMMultiplikationsoperatorMetrisches SystemVerschlingungComputeranimation
29:54
Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:07
Hello everybody and welcome back to the distributions Dev Room here at Fosdem 22. My name is Tilo and I'll be talking about modding the immutable. It's about modifying the operating system image of flat-card container Linux, a immutable image-based Linux distro.
00:23
First, let me make room for the slides and let's get started. Hi, I'm Tilo. I am an engineering manager at Microsoft. I work with the flat-card container Linux maintainers team. You can find me on GitHub, you can follow me on Twitter, you can just drop me an email.
00:41
Today, I'll be giving you a brief introduction into flat-card container Linux so that you get an idea of what this distro is about and then we'll look into building your own operating system image, making modifications so you can build your own customized image and I'll give a brief note on testing.
01:01
But first, what is flat-card container Linux? Just a state of mission statement. We are fully open source, minimal footprint, secure by default and always up-to-date Linux distro for running containers at scale and we only run containers. We don't ship any package management or any other way to extend the system after it's been provisioned.
01:20
We work with a minimal immutable base system. We have a very fixed set of tools. There are no add-ons native to the operating system. We have a strong focus on container workloads. You want your favorite tool, use the container. You want your favorite app, use the container. That gives us a very strict separation between the operating system and the applications which is great for maintenance.
01:44
We ship as an image so there is no package management. You can't DNF at anything. The operating system part of the image is immutable. You can't really delete or modify the operating system binaries at runtime.
02:03
The updates to the operating system are shipped as images too. Just to give you an idea and to get a little bit into partitioning. After you've provisioned a node that runs flat for Linux, you'll have two operating system partitions which we call partition A and B
02:21
and that's for atomic updates. You have an OEM partition that has vendor specific drivers for operating. For instance, in AWS, on bare metal or in Azure, you have a root partition. Root is read-write but root doesn't contain many binaries from the operating system.
02:42
It's just configurations, your home directories and any binaries that the users may have dropped there. Now the operating system partition is mounted as a read-only partition under slash usr and this partition can't be written to. All our operating system libraries and binaries reside in usr
03:05
and usr as mentioned is read-only so you can't really mess with stuff. The operating system from a more distant point of view is treated as an application so you can upgrade, downgrade, roll back, roll forward
03:20
and actually there's a container's devroom talk just on that aspect of flat for Linux that is focusing on automated updates. We have regular and very rapid releases. Alpha, which is developer focused, releases roughly every two weeks, a new major release. Beta is for canary testing, has a release of every month
03:41
and the stable channel releases every two or three months. Now for modifying the operating system, we will create our own operating system image. We're using the SDK and we're getting some hands-on during this talk to just do that. Flacker is based on gen 2 so we'll build everything from sources
04:03
except when we base our modifications on an existing release, we also provide service binary package caches that can be used to just make everything a little faster. There are other options to modify Flacker Linux even after it's been provisioned.
04:21
For instance, you could instrument the provisioning logic to download your own custom binaries to the read-write root partition and then use those static binaries to add functionality and features that you require. You could do more advanced stuff like adding a writable overlay over the USR directory
04:42
and then use the dev container for instance, which contains toolchains that allow limited compilations to just modify packages or even add custom kernel modules after an instance has been provisioned. Today's talk's goal is to put you in a position to modify the operating system image and create your own images.
05:02
For instance, you could use that to add or update packages and fire PRs to our upstream project. PRs that go into the project need to adhere the mission statement which is we are small, we are secure and we are container focused. Apart from that, we are absolutely open for your contributions.
05:22
You could fix bugs that have been bugging you while using Flacker or you could just look and see what bugs other people are running into and then help with that. It's a great opportunity to get your hands dirty in operating system development. You could even, when you run images, become your own upstream and go from there.
05:45
To get started with Flacker, we'll be looking at the Scripts repository. That's like the central entry point for Flacker development. It could also be called the Flacker SDK repository. Scripts is a legacy name. Scripts contains submodules and all of the components to build the operating system image
06:04
and it contains wrapper scripts for using the SDK container. Let's get started and let's get us a copy of the Scripts directory. For the remainder of the talk, we'll be using a subdirectory to work in
06:21
and we'll start by just pulling the latest clone of Flacker scripts. Here we go. We're using submodules for the actual package e-builds. We want to initialize the submodules and make sure they're up to date.
06:48
That's pretty much it. Now, the next thing you want to do is you want to pick a release version. This release version will be used to base our own changes on top. This release version should be as close to the main branch as possible
07:05
while at the same time being stable enough to take our changes. Now, Flacker releases in branches. Every roughly two weeks, a new alpha release is branched off our main branch
07:20
and it's been tagged in that release branch as an alpha release. Some alphas actually go beta. Not all of them do. A new alpha is branched off and after due hardening and due growth,
07:42
an alpha can transition via beta to stable. This is basically how the operating system versioning works. Now, clients using Flacker can subscribe to any of those channels for updates. It's usually determined by the initial channel that they've been provisioned with.
08:03
You receive updates from that channel. Stable is basically super stable, super hardened and can be used for operations. Beta has a limited use for ops and is used for canneries and alpha is used for development.
08:23
Since we're developers, we will be picking the latest alpha release. We're looking for the latest alpha release branch. It's a solid foundation to build our images on. It's well tested and binary packages are available so we don't need to compile everything ourselves. It's still reasonably close to main which can be considered alpha next at any given point in time
08:46
so that we will be able to merge our changes upstream without much hassle if we desire to do so. Let's find the branch that we want to use.
09:01
We just sort basically the release branches and look at the latest five branches. We see that the most recent branch is 3115. If you look at the release webpage, then we see that is indeed the latest alpha release. We should use that branch.
09:20
We supply a tool called checkout. Checkout takes either branches or tags and does the right thing to keep your source tree up to date and also updates the submodules. After checking out, you can just start a wrapper script that will then run the SDK container for us. Now, the SDK container is reasonably big so your download will probably take a little longer than shown here.
09:46
It will put you right into the flat cut SDK after it's been started. We're seeing here that we're developing the alpha version but there is a get tag after the version number and that says that there are commits after the last alpha release which is perfectly fine.
10:04
The alpha release branch is considered stable enough. You can check the version file and find our operating system image version and the get tag on top of that which builds the overall version as well as the SDK version that we're using.
10:28
Now, the thing we're going to do now is we just rebuild the state of the current alpha and that mainly aims at making sure that everything is okay and working. We have a solid base to base our changes on.
10:44
We will build all the packages which won't really build packages because we can use binary caches since we're basing on a release version and then we build the operating system image. That will take some time. After that, we'll just start the image in a local virtual machine and see if everything's working.
11:03
To give you an example of what it looks like, we provide a wrapper script that actually does all of the heavy lifting for you. We're going to build all of the packages that won't really build all of the packages but download those and install that into a local change route.
11:21
Let's look at that change route inside of the SDK. That is a cross compiler change route. We're using just plain general cross tools here and that includes the operating system image. It also includes all of the binary packages and that will be important very soon when we start building the operating system images.
11:44
That cross compiler change route actually has its own portage and its own package sets and we'll find all of the packages that make up the image right there.
12:04
All right. We just downloaded all of the binaries from the package cache which would usually have been built locally if there was no package cache available for the version that we're using and install those into a change route within the SDK. We're using cross compiler change routes to separate the SDK from the actual operating system image.
12:28
That allows us to generate a way leaner image that we would be doing otherwise. Now that we created all this, we can go ahead and use those binary packages
12:41
to actually create a OS image from. That is done by another wrapper script which is aptly called build-image. Build-image takes about half an hour to run usually to create the operating system image. We fast forwarded that for you a little so that you don't have to wait.
13:02
At the end of the process, you will have a generic binary that has all of the OS binaries in it. Let's look at the binary real quick. It's in an output directory within the SDK. That output directory is also bind-mounted from the host.
13:24
If you look at the production image binary here, then we just leave the container real quick and have a look from the host. Then you'll see that on the host in the build output directory,
13:42
some subdirectories, there's also the same binary image. Let's share it between the container and the host. That's something that the wrapper script does for you. That's why we're using a wrapper script. You can easily integrate with both host and SDK tools.
14:03
All right, let's enter the SDK container again and turn this generic image into something that we can directly use. There is another helper script called image2vm.
14:22
Now image2vm generates vendor-specific images. If you want to run this in AWS or in bare-metal, IPXE, as in ISO or in QEMU, then image2vm can actually help you there. The default output of image2vm is QEMU. That is what we're currently looking for
14:41
because we want to just run it locally. We just give it the directory that our generic image has been generated and it'll get us a QEMU image. It'll also add a handy wrapper script, which we can use to just run the image locally,
15:02
and that is flatcar production qemush, which we're going to use in a second to just boot flatcar in that output directory. Just take note of that. That'll allow us to SSH into the machine. The QEMU wrapper script boots the flatcar image
15:24
in QEMU user mode, so you don't need any root access for that. You just run the script and you'll have your flatcar. There we go. It needs a few seconds to boot up.
15:43
Let's put it in the background so I can use the same shell to SSH into the image. We use a custom port, obviously, because we don't want to conflict with your host ports and we don't want to use privileged ports, and here we are. This is our self-built operating system image.
16:01
It's entirely self-made. You'll see that the version that we're seeing is the same as the version from the checkout that we've been looking at. Now, what did we just accomplish? We created more or less a carbon copy of a flatcar release. We've built the operating system image without changes
16:23
by first fetching and installing to a local change root all of the packages that make up the base OS image and then building a base OS image from that. We then built a vendor-specific image that runs with QEMU,
16:41
started the image, and checked that everything was working. Now, that is nice, but to actually leave your own footprint, to bring your own ideas into the operating systems, you want to make a change. You want to add a package. Now, this is to keep it relatively easy.
17:02
We can just import a package from Gen2. Gen2 has a vast variety of well-maintained packages, and we can just basically use e-builds from Gen2, import them to flatcar, and make it work for us. There are minor e-build skills required. We will be looking at the e-build, but it will really be some very local and limited modifications
17:25
that we need to do. Now, one tool that is not included in flatcar and that I just love, that is the tool Screen. For the purpose of today's talk, we'll be looking into shipping Screen with the flatcar operating system image.
17:42
Where are the packages? Where is all the stuff that gets your image built? The scripts repo comes with a number of wrapper scripts that help for building packages and images and even rebuilding the SDK. But it also comes with two Git submodules called ChorusOverlay and PorridgeStable
18:02
that are Gen2 layers and that we use to define the package builds. Now, the scripts repo is bind-mounted into the SDK container. Inside of the container, it's at home SDK and then a subdirectory. All of the package builds, e-builds are also available
18:22
both in the container and outside of the container on the host. We now have a rough idea where to put the e-builds that we're going to import from Gen2. Let's do the hands-on and see how that is done.
18:43
First, we're going to go one directory up and we actually clone the Gen2 GitHub repo with a shallow depth because that repo is really, really big. So that is happening here and then we'll look into the Gen2 repo
19:01
and find the screen e-build and then import it to the Flatcar SDK. Now, there is our Flatcar dev and all Gen2 directories and we're going to go down to the point where the e-builds are in Flatcar.
19:22
The Portage Stable is pretty much a snapshot of Gen2 at an earlier point in time and the Coros overlay is a repo that contains more Flatcar-specific modifications. If you just copy a e-build from Gen2, it'll go to Portage Stable.
19:43
If you modify that e-build and make it more Flatcar-specific, it should go to Coros overlay. First, we look in Portage Stable. There's no screen and then we look in Coros overlay just to be sure and there's no screen there as well. Let's quickly check this screen e-build
20:02
and it looks all reasonable. It only has a limited set of dependencies, which is very important to keep Flatcar lean but it depends on techie info for building and for running and that is something that we want to get rid off of.
20:20
The Flatcar operating system image ships without mount pages, without any documentation because it is supposed to be operated automatically on server nodes that run containers so we might want to remove that. Having understood this, it becomes pretty clear where the screen e-build needs to go
20:41
and that is to Coros overlay. The reason for that is we're going to modify the e-build. It will not be a carbon copy from Gen2 upstream. Here we go. Let's edit the screen e-build. After we've copied it, let's remove the dependencies
21:02
that we don't want to have in the operating system image. Let's go down and actually remove the part that creates the documentation and that's about it. Things should just go on and work now. All of the other dependencies are inside of Flatcar are available.
21:22
Let's go back to our clone of the scripts repo, start the SDK container and just use this e-merge command to emerge the screen tool inside of the cross compiler change route that we use to separate the SDK from the operating system packages.
21:43
Compile is pretty straightforwardly. If there was a dependency issue, then we would already have seen it at this point and it seems to go ahead everything and it works. We can now take a look at the cross compiler change route
22:04
and we can check if the screen package actually has been created in the respective package cache and there it is, screen 4.8. That means we can build it for Flatcar and it will run in Flatcar.
22:21
Now the thing left to do is we need to go ahead and add the screen package to the list of dependencies for the operating system image. The operating system image is just a many build file itself.
22:43
We're going to go here and find it and we're going to edit it and if you check this file then you get a brief instruction of what should and should not go into the operating system image and you just see a huge list of rd pens and these are basically all of the packages
23:01
that make up the base image. We find all those on the base image and of course the respective dependencies of those packages. Let's edit here. Keep things in alphabetical order. That is screen and now the last thing that we need to do in order to apply those changes
23:21
is we need to emerge into the cross compile change root the base package that we've just edited because the second script we're going to use and that is build image will only look into the cross compile change root and will not look anywhere else.
23:44
Now let's build the image. Again, we're going to do a little bit of fast forward here but first we already built an image of the version that we're looking at so we're going to tell build image to please replace what has been built otherwise it's just a board and ask you to use the replace flag
24:02
if you're really serious. We are, so we're doing that. This is fast forward again because you really don't want to wait those 23 minutes that it'll take to just reinstall all those packages and if you pay close attention then you'll see that we have built
24:22
254 packages this time. Last time it was 253 and that's a clear hint that a package has been added. Now we're using image2vm again to, like previously, create a QEMO image for us so we can boot and we can check if our modification
24:41
actually applied to the image. Let's go on the host outside of the SDK container go into the results directory and just run the QEMO script like we did before
25:00
with the unmodified image. There we go. Let's push it in the background. Let's SSH into it and have a look.
25:34
Is there any screen installed? Yay! We have screen added to the operating system image and we can use it.
25:40
Screen works and we just open two screen sessions here switch back and forth and check that basic functionality does what it's supposed to do. And that's pretty much it. That's all there is to the magic.
26:02
We just did is we created our very own personalized operating system image with the one tool that we all crave. We introduced a new package based on an upstream build and then we just rebuilt the OS booted into the OS and validated our changes. That's pretty much the workflow that you do
26:20
when working on flat card changes. There is a brief note on testing. Testing for flat card just deserves its very own talk and it's got its very own talk. That's the talk. All is well. Test well. Bye. So if you have a chance look for the recording. The talk has a lot more insight
26:41
into our test tool Koda than I can cover in my talk. So Koda is a release test tool. It covers a very broad range of tests. For today's purposes we only run like a very limited set. That is the basic test suite. You can understand this like smoke testing.
27:01
It can help you to just get an idea of you know the basic things, booting, basic services are still working and broken. So we can run this inside of the SDK container which also ships Koda. So we're going to go into the results directory inside of the container
27:21
and run Koda and this test is we'll be using QEMU to spawn a number of instances so it's able to run networking tests. It needs sudo because it uses the host server networking part of QEMU
27:40
so it needs to be able to create tap devices and so on. It is based on the generic image so this isn't even based on the QEMU image that we created with image2vm and here we go there's a number of subtests that Koda executes and everything is green and we're happy.
28:01
So Koda outputs a results file in tap format and if you're familiar with testing then there's a lot of tools that can help you visualize tap and post-process it. Now this tap content is relatively basic because we only ran the basic
28:21
smoke testing but we validated that the operating system is at least in very basic base functional. Now something else that you can do at this point is you can actually go into the modified directories.
28:42
So you can have a look at Chorus overlay and have a look at the changes. You'll see we've added the file and we've added the file so let's make this new directory known to Git without staging the changes. You could easily run a git diff now, see all of the changes and you could use
29:02
that to git diff into a patch file and then use that patch file to for instance file a PR and see if we're interested in adding screen in the upstream project.
29:22
And that's pretty much all for today. If you want to see this talk as a document that basically handles you step by step have a look at the first link. If you want to just have a chat with us, we're on metrics. If you want to contribute, check us out on GitHub.
29:41
It's pretty easy and we're very welcoming. Or you could even make your voice heard and join our monthly community calls. If you have any questions then now would be a good time.