Installing openSUSE only with SaltStack
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 40 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/54407 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
openSUSE Conference 201930 / 40
7
11
12
13
15
16
17
18
19
20
23
25
26
27
34
38
40
00:00
Lie groupDifferent (Kate Ryan album)Installation artPerfect groupDirection (geometry)Stack (abstract data type)WordVideo gameMereologyComplete metric spaceConstructor (object-oriented programming)MassMiniDiscHand fanTouch typingAuthorizationUML
01:15
IdempotentBuildingInstallation artParallel portVertex (graph theory)Configuration spacePlastikkarteComputer fileSimilarity (geometry)Personal digital assistantLatent heatData storage deviceState of matterData structureDigital rights managementProcess (computing)Content management systemPlane (geometry)Decision theoryMatching (graph theory)Exterior algebraSemiconductor memoryGoodness of fitFamilyHard disk driveLibrary (computing)File systemProcess (computing)Mechanism designVertex (graph theory)Decision theoryType theoryPlanningData storage deviceInstallation artDifferent (Kate Ryan album)CASE <Informatik>Latent heatFile formatProfil (magazine)Computer filePresentation of a groupTemplate (C++)Classical physicsSet (mathematics)Configuration spaceEndliche ModelltheoriePlastikkarteSoftwareChainFunction (mathematics)Flow separationData loggerCentralizer and normalizerPoint (geometry)Complete metric spaceMiniDiscFormal languageGame controllerState of matterModule (mathematics)Metropolitan area networkPoint cloudVideo gameEmailMultiplication signStructural loadBoss CorporationWorkstation <Musikinstrument>Game theorySpecial unitary groupSubject indexingCuboidRoundness (object)InternetworkingBootingEscape characterPhysical lawArtificial neural networkFocus (optics)Constructor (object-oriented programming)AuthorizationObservational studySound effectPhysicalismMereologyService (economics)Projective planeMathematicsFigurate numberLink (knot theory)Computing platformStaff (military)Group actionMusical ensembleTrailTime zoneWindowNeuroinformatikFacebookDiallyl disulfideComputer animation
07:36
State of matterConfiguration spaceSoftwareDigital rights managementArchitectureDefault (computer science)Element (mathematics)outputCategory of beingModul <Datentyp>CodeParameter (computer programming)Module (mathematics)Physical lawVertex (graph theory)Tablet computerData structureUniqueness quantificationFormal languageLogicTemplate (C++)Mechanism designState of matterSolid geometryWeb 2.0Special unitary groupAddress spaceNumberLatent heatEndliche ModelltheorieMereologyModule (mathematics)ChainProcess (computing)Group actionDecision theoryWritingDifferent (Kate Ryan album)Vertex (graph theory)Game controllerComputer architectureConfiguration spaceCategory of beingPublic key certificateInformationInstallation artSoftwareConnected spaceParameter (computer programming)AbstractionSubsetShape (magazine)Query languageBus (computing)Element (mathematics)Hard disk driveSemiconductor memoryIP addressComputer programConfiguration managementHardy spaceInternet service providerFlow separationWordTopostheorieWorkstation <Musikinstrument>Visualization (computer graphics)Logic synthesisFraction (mathematics)Game theoryMultiplication signData managementTape driveStack (abstract data type)Musical ensembleVideo gameInternet forumGrass (card game)Content (media)Level (video gaming)Cue sportsSuite (music)MetrologieStaff (military)ResultantWebsiteVideoconferencingComputer file1 (number)Scripting languageVirtual machineMiniDiscComputer configurationView (database)Discounts and allowancesLogicHand fanPhysical systemComputer animation
13:09
State of matterVertex (graph theory)Data structureUniqueness quantificationFormal languageLogicTemplate (C++)Mechanism designFile systemRootModule (mathematics)InformationSystem programmingPhysical systemBootingPartition (number theory)Convex hulloutputCodeConfiguration spaceIntegrated development environmentGroup actionExplosionElectric currentDrop (liquid)State of matterDifferent (Kate Ryan album)Traffic reportingoutputGroup actionConfiguration spaceSoftwareFile systemParameter (computer programming)Computer hardwareLogicStatement (computer science)Mechanism designWebsiteDescriptive statisticsPublic domainException handlingLevel (video gaming)MiniDiscSet (mathematics)CuboidPersonal digital assistantSubject indexingAnnihilator (ring theory)Roundness (object)ChainMachine visionFault-tolerant systemMathematicsProof theoryInequality (mathematics)Video gameMatching (graph theory)Expected valueGame theoryDistanceFlagExpert systemHypothesisSoftware testingAmsterdam Ordnance DatumMobile appStack (abstract data type)Validity (statistics)View (database)Stress (mechanics)Electronic visual displayRight angleCASE <Informatik>Time zoneDecision theoryPartition (number theory)Element (mathematics)PlanningSingle-precision floating-point formatVector potentialShape (magazine)Compass (drafting)Product (business)Order (biology)AbstractionFerry CorstenVertex (graph theory)Template (C++)Electronic mailing listDeclarative programmingDirectory serviceError messagePoint (geometry)Game controllerAxiom of choiceBitComputer fileHard disk driveCategory of beingPairwise comparisonComputer animation
18:34
SharewareModule (mathematics)CodeConfiguration spaceoutputIntegrated development environmentGroup actionExplosionElectric currentBootingRootInstallation artVertex (graph theory)Holographic data storagePartition (number theory)Single-precision floating-point formatScripting languageComputer-generated imageryVirtual machineGoodness of fitInstallation artNetwork topologyPhysical systemMobile appScripting languageSelf-organizationPartition (number theory)Different (Kate Ryan album)Hard disk driveMaxima and minimaVirtual machineInheritance (object-oriented programming)FacebookEinstein field equationsGroup actionInformation securityMereologyInternetworkingSingle-precision floating-point formatFlow separationConfiguration spaceSharewarePlanningPhase transitionFile systemBootingComputer animation
20:14
CodeReading (process)Open sourceSharewareRootState of matterPatch (Unix)Configuration spaceRadical (chemistry)Medical imagingVertex (graph theory)MathematicsGraph coloringRight angleEvent horizonVirtual machineComputer architectureDiagramCartesian coordinate systemBus (computing)BitPresentation of a groupVideo gameCASE <Informatik>Noise (electronics)Branch (computer science)Identical particlesSoftwareSinc function
22:33
Vertex (graph theory)RootInstallation artPartition (number theory)VolumeBootingState of matterModul <Datentyp>Compilation albumLevel (video gaming)AbstractionSoftwareSelf-organizationData storage deviceRAIDMaß <Mathematik>Parameter (computer programming)Condition numberForm (programming)Communications protocolControl flowInterior (topology)Event horizonMacro (computer science)Motion captureComputer wormMiniDiscMassPartition (number theory)Level (video gaming)State of matterOrder (biology)RootInternet service providerString (computer science)Complex (psychology)Power (physics)Physical lawVirtual machineReal-time operating systemVideo gamePreconditionerFrequencySpecial unitary groupMereologyExtension (kinesiology)Element (mathematics)Exclusive orWebsiteAbstractionAreaService (economics)LogicBuildingInstallation artInformation securityDiscounts and allowancesConfiguration spaceVolume (thermodynamics)Link (knot theory)Process (computing)Event horizonPhysical systemBootingTwitterSoftwareMacro (computer science)MathematicsSolid geometryCondition numberMultiplication signExpressionEndliche ModelltheorieLatent heatGroup actionMechanism designException handlingDecision theoryTraffic reportingThomas BayesInjektivitätExpected valueBEEPPoint (geometry)Data storage deviceComplete metric spaceComputer configurationKey (cryptography)Bit rateShape (magazine)Network topologyFunction (mathematics)BitSoftware developerBus (computing)Projective planeExecution unitBranch (computer science)Source codeFerry CorstenBootingServer (computing)Menu (computing)Computer animation
29:14
Product (business)System of linear equationsInstallation artComputer networkConfiguration spacePlastikkartePartition (number theory)Data storage deviceComputer programmingConstraint (mathematics)Control flowElectric currentInstallable File SystemVolumeRAIDBootingSoftwareImage registrationDigital rights managementPasswordLocal GroupSet (mathematics)DisintegrationState of matterEvent horizonMacro (computer science)Analog-to-digital converterMultiplicationArchitectureImplementationCodeStreaming mediaModule (mathematics)Process (computing)PrototypeKolmogorov complexityDivisorRevision controlComputer-generated imageryModul <Datentyp>RAIDInformation securityPartition (number theory)MiniDiscWritingBitRaw image formatSlide ruleConfiguration spacePhase transitionSet (mathematics)Internet service providerData storage deviceConstraint (mathematics)Decision theoryInstallation artIterationExtension (kinesiology)Projective planeRevision controlProduct (business)Element (mathematics)Game controllerMechanism designPhysical systemPatch (Unix)Mathematical optimizationOrder (biology)Multiplication signComputer fileLinear programmingShape (magazine)State of matterFerry CorstenINTEGRALSoftwareMereologyLevel (video gaming)Network topologyBootingKey (cryptography)Group actionGoodness of fitObservational studyRight angleWeb 2.0EmailString (computer science)TwitterInterior (topology)MathematicsCue sportsDiagramForcing (mathematics)Macro (computer science)Video gameScatteringEuler anglesStreaming mediaThomas BayesGodDiscounts and allowancesDistribution (mathematics)Natural numberHand fanEinstein field equationsSound effectComputer programSoftware testingLine (geometry)Physical lawWater vaporLink (knot theory)Social classFeedbackMultiplicationUniform resource locatorBeer steinSpecial unitary groupMusical ensembleRandomizationArtificial neural networkBuildingProcess (computing)Image registrationSolid geometrySoftware developerInverter (logic gate)Advanced Boolean Expression LanguageComputer animation
36:51
Statement (computer science)MiniDiscPartition (number theory)Constraint (mathematics)Linear mapComputer programmingInternet forumZielfunktionAlgorithmSimplex algorithmSpacetimeFunction (mathematics)RootExpected valuePartition (number theory)Maxima and minimaLimit (category theory)SpacetimeConstraint (mathematics)Decision theoryLinear programmingVirtual machineHard disk driveSet (mathematics)SummierbarkeitRule of inferenceAcoustic shadowPoint (geometry)LogicCASE <Informatik>Installation artState of matterSoftwareComputer hardwareAlgorithmWeightFunctional (mathematics)Range (statistics)Mathematical optimizationBitGame controllerEqualiser (mathematics)MiniDiscComputing platformField (computer science)Computer programBus (computing)QuicksortAnalytic continuationWave packetInheritance (object-oriented programming)ExpressionLattice (order)GoogolWindowMultiplication signWater vaporKey (cryptography)Roundness (object)Service (economics)Group actionFormal languageOffice suiteChannel capacityPhysical lawHand fanLink (knot theory)Classical physicsBit rateFingerprintMathematical analysisNoise (electronics)Distribution (mathematics)MathematicsSubject indexingComputer animation
41:16
Term (mathematics)SharewarePartition (number theory)Hard disk driveDifferent (Kate Ryan album)Einstein field equationsPresentation of a groupDecision theoryGame theoryCausalityStrategy gameState of matterVertex (graph theory)Matching (graph theory)MereologyFunction (mathematics)Source codeXML
42:50
SoftwareInstallation artRandomizationoutputField (computer science)Discounts and allowancesHydraulic jumpWindowSpecial unitary groupLatent heatInformationFlow separationSynchronizationReading (process)DatabaseWeb 2.0Data storage deviceService (economics)Squeeze theoremSemiconductor memoryPublic domainSheaf (mathematics)Group actionPhysical systemPhysical lawMaxima and minimaState of matterMedical imagingBootingMechanism designPublic key certificateInjektivitätDatabase transactionMassStaff (military)Twin primeOffice suitePoint cloudCanonical ensembleCubic graphElement (mathematics)Configuration spaceMultiplication signRAIDGradient descentGame theorySampling (statistics)Content (media)Video gameTelecommunicationNuclear spaceExistenceShape (magazine)Pattern languageVertex (graph theory)Open setRootValidity (statistics)Sign (mathematics)Hard disk driveFerry CorstenProcess (computing)Operating systemMereologyKey (cryptography)Arithmetic progressionCubeOcean currentSource code
48:07
SoftwareRepository (publishing)RootPasswordFile systemSharewareDefault (computer science)Mathematical optimizationBootingSoftware repositoryMathematicsComputer architecturePattern languageKernel (computing)RootSoftwareMiniDiscMultiplicationPartition (number theory)Public key certificateOcean currentCuboidState of matterBoss CorporationPhysical systemSystem administratorInternet forumModule (mathematics)Product (business)Annihilator (ring theory)Decision theoryAnalytic continuationLink (knot theory)Single-precision floating-point formatField (computer science)Computer hardwareComputer configurationFile formatMultiplication signFamilyLevel (video gaming)Information technology consultingFormal verificationConfiguration spaceMaxima and minimaSpecial unitary groupBuildingInternetworkingLogicBroadcasting (networking)Observational studyPlanningNeuroinformatikRevision controlYouTubeDistanceFlow separationGroup actionPower (physics)Standard deviationMathematical singularityMechanism designStability theoryWebsiteEvent horizonComputer fileServer (computing)Vertex (graph theory)CodeMoore's lawCore dumpInstallation artDifferent (Kate Ryan album)BefehlsprozessorBus (computing)Message passingBootingNumberVirtual machineCASE <Informatik>Image resolutionElectronic mailing listEndliche ModelltheorieResultantSet (mathematics)FlagArithmetic meanComputer animation
53:06
Default (computer science)BootingPattern languageKernel (computing)RootEndliche ModelltheorieLine (geometry)Point (geometry)View (database)Tap (transformer)TouchscreenRight angleServer (computing)Connected spaceService (economics)File systemLinear programmingIdempotentMechanism designPhysical systemPartition (number theory)Virtual machineFlagProfil (magazine)CASE <Informatik>Level (video gaming)Installation artWordImplementationState of matterRevision controlBootingDifferent (Kate Ryan album)Distribution (mathematics)InformationWeb 2.0MereologyMedical imagingData managementSystem callMarginal distributionSpecial unitary groupSet (mathematics)Exception handlingTablet computerMatching (graph theory)Electronic program guideDensity of statesSubject indexingPhysical lawDiscounts and allowancesMassMachine visionTouch typingComputer architectureBlock (periodic table)MathematicsControl flowVideo gameTowerComputer animation
58:08
Videoconferencing
Transcript: English(auto-generated)
00:07
So hi. So welcome, and thank you for coming to my talk. So I am Alberto Planas. I am part of the SUSE team.
00:22
We are going to talk today about Yomi. Yomi is the acronym of Jet One More Installer. If you know something about manga or anime, you know that also Yomi is a kind of a door that is connecting the word of life with the word of death.
00:42
So we are going to try to cross this door in the other direction with Yomi. And basically, we are going to talk about how to install OpenSUSE using only a sold stack. So you know that there is different ways, different technologies to install OpenSUSE. We have Autoyast. We have many others.
01:02
But we are going to use today only sold. So how many of you know about sold? What is an install? Perfect. This is going to be super fast. So what is Yomi? So it's a new type of installer. As today, I really hope that it's going to change.
01:22
It's only focused for the OpenSUSE family. So micro SSD, Tamil root, of course, lib. It's designed to throw installations when you have a couple of heterogeneous nodes.
01:41
So imagine that you have nodes that have a different CPU, different memory configuration, different hard disks. So when you have this kind of problem, Yomi is a good match for that. In that regard, it's an alternative to Autoyast, because Autoyast has also this capability.
02:03
So it's designed to make the installation in an attended way. So it's a way to throw thousands or hundreds of installations and be complete until the end without user intervention. For that, we need to use some kind
02:22
of smart configuration file. In that case, because sold is using YAML, we are using YAML together with some template engine. In this case, it's Jinja 2. There are other template engines, but Yomi's using Jinja. One of the requirements is that it's a very good thing
02:43
to have some kind of central point of decision, so some kind of compute node, some kind of orchestrator that is going to make decisions when something needs to be decided. Because it's built on top of salt,
03:00
we want also the potent in the potent in the potent, sorry. So this kind of feature that an estate have, that when you apply something several times, the output is going to be the same in each case. And we want something that can work alone,
03:21
but mostly can work integrate into a bigger solution. So that means that we want that installation. It's nothing special during the provision of the workflow of the provision of the client. So we want that the install is only one step and maybe it's not even the first one.
03:43
As I say, it's an alternative to Autolyas. I mean, Autolyas is a chair, this kind of goals. In that case, we are not going to use any specific library. So for example, in Autolyas, we have libstory 10g, and we have another set of ecosystems,
04:02
a set of libraries that are explicitly designed for the installation process. Apart from that, they are not very used. So we want, in that case, have a very small chain of dependencies. So basically, nothing apart from salt. So we are going to use the upstream salt models
04:20
together with the new models that we are going to provide. Those models are going to live not in Yomi, but in upstream. So everything is going to be living in salt in this project. And of course, at the very low level, we are going to use the classic tools like Part-S, chroot, BatterFX, or SIPL. But basically, the CLI that you will use
04:43
if you drive the installation manually, nothing else. And this, if you manage that, you are going to have a set of advantage. One of them is that, so if you know Autolyas, you have this XML that is a profile that you design specifically for certain compute,
05:02
for certain nodes in your network. The good thing about using salt is that this configuration file that is kind of present in Yomi can be managed in a very DevOps way. So you are going to use the classical tool that DevOps is going to use,
05:21
like Git, NFS, database, or whatever other mechanism to manage the configuration. And they are going to reapply all this knowledge and tool for the installation process, nothing specific. I think that another benefit that is going to have is less burden for the DevOps
05:41
when he need to apply the knowledge during the monitoring, inspecting logs, understanding when something goes wrong, what is happening. Because we are going to use the classic tools and the logs files are going to be in the place that always are living and the format and the way to extend those log files
06:01
are exactly as salt or because we are using salt, basically. So there is not a specific knowledge to understand what happened when something goes wrong during installation process. Also, it's more easy to debug what is happening and fixing. So again, the use case is very clear.
06:21
So we want to, we have a cluster. This cluster has different kind of nodes. They are going to have, we can imagine in OpenStack, in Cloud, in Kubernet that we are going to have different kind of roles. So there are certain nodes that are going to be used for the control plane. So maybe they have a very big CPU, a lot of memory.
06:42
There are nodes that are going to have not so big hard disk. So they are not going to be used for storage but they are going to be used by the CPU. There are other compute nodes or other nodes they have very long rack of hard disk and they are going to be used for storage. That means that the kind of file system
07:02
that we are going to apply on them is going to be different. So we have these kind of different nodes. Jom is going to help us to orchestrate the installation and decide what exactly is the better way to configure this node for the use case that we want.
07:21
In that regard, we need some kind of intelligence for the installers. So we don't want to separate the making decisions from the installing process. So we need some kind of mechanism that we are going to provide with Jom. So this is a one-on-one of solid state because most of you know about Sol.
07:42
This is going to be fast but basically a solid state is, well, Sol is a configuration management software. So it's kind of a chief of Ansible, Puppet or any other one that we have. Something cool about, and I think this is specific of Sol, this that is very modular and you can decide how you can make the architecture
08:02
of your Sol solution. So you can have an optional master. You are going to have an optional minion installed in the node. You can use, if you don't have a minion, you can use SSH for the connection and taking control of the node. You can execute certain scripts
08:22
and certain states locally without the master intervention and you are going to make the same decisions. You have different kind of modules that are called reactor, Miners, Sol API that is going to help you to provide a very specific solution for the kind of network that you have.
08:42
And this is something that is also be very critical for Jomi because it's expected and it's doing, that is going to work for this kind of configuration. So you can use Jomi in a masterless configuration. You are going to use Solt API to understand what is happening inside the installation process.
09:01
You can use Solt SSH to bootstrap some initial configuration. So you have all these kinds of tools and configurations for resolving the problem of the installation process. Yeah, you know, so Solt is using different concept. One is the grain that is the information local to the node. Something specific that describe
09:21
the properties of the node that you want to address. You have something that is pillars that is basically some kind of data that is kind of, we can say that, where you store certificates or configurations or you store some kind of data
09:41
that is going to be used later for making decisions. You have something that are the execution models. This model is basically some action that is executed in the minion. It's anything. So for example, it's the installation of a package or mounting a hard disk. Everything that is an action is an execution model.
10:01
Usually it's writing in Python, so everything is there. On top of the execution model, you have the states. A state is like an abstraction of the one or several execution models. So it's like a chain of action. It's more complicated than that because it's going to provide you some guarantees about the execution model
10:22
that is going to be launched when the state is applied. And we have some kind of states describe it in a YAML documentation file. That is a way to instruct the minion to execute a salt module.
10:42
So it's a kind of an state model. The typical architecture in salt is something like that. So for one side, you have salt master. Inside the salt master, you are going to have, this is basically a specific matching your network. You are going to have the pillars,
11:01
so the data that is going to be shared between the minions. You have the states. You have the state in the YAML documentation, so some document that is going to be the YAML. You have the state model, so the Python part that is going to implement the states. And you have the execution models, so you have everything installed there.
11:21
In the other side, you have different minions. Each minion is going to publish some data that is called the grains. So everyone is going to say, okay, my MAC address is that. My IP address is this one. My ID is that. I have this number of hardys and this number of memory.
11:42
This, the minion is connected through the master via a bus, so you have a channel that you can use in different ways. So it's a resource that the programmer or the user of salt can use for different stuff. But this is the bus that is used for connection,
12:02
for connecting the minions with the master. And basically, this is the full architecture. You can change every element from here. But we can start thinking about that. So again, pillars is the data. We know exactly what is, so it's the data that is, the YAML document that is going to contain
12:21
the data required by the state. So if you want to apply an state, you can read the data for a specific node via the pillar. So you can read in the pillars what parameters you are going to pass to the state.
12:40
Something interesting is that those pillars can be mapped on top of different nodes using a query language. So depending on some specific data that is living in the node, like the grains or some other features, you can map a subset of the data to this specific node.
13:05
And it's a kind of data that contains logic. So optionally, this data can have different shapes according to some logic that is applied before you apply the state in a node.
13:22
So it's more than raw data. This is an example of a pillar. So something raw is in the gray box. It's a description, it's a tree alike. In that case, it's the description of a file system. So in that case, it's only a description of a hypothetical two hard disks
13:42
or one hard disk but two partition file system. There is nothing special in this description. I decide what is going to be there and I decide what data I'm going to apply that. These data have only meaning for the state. So the state need to understand that
14:00
but as the person that decide what is going to be there, I can make different choices. And again, I can provide this bit of logic in the data. So in that case, in the yellow box, we can see that there is some kind of decisions based on something that is the ID that is living in the Grains data.
14:23
So depending if of the kind of ID, we are going to expect one file system or another depending if it's a controller or compute node. So you have an intuition about how this kind of template mechanism can change the shape of the data
14:41
that you are going to apply into the nodes. You have a state, it's again this document, YAML document that has this shape that is going to describe what do you want to apply and which data you want to apply to a specific node.
15:01
So in the top box, you can see this create, mount create file system tab. So this is a way to mount a device. This is declarative, so you can see that you are not describing how to do that. You are only describing what do you want to have. The state is going to take care that
15:21
if the mount point is not there, he can create that. So it can create the directory empty if it's not there. If the hard disk is not present, it's going to show an error message. If the file system is not the one that you have, it's also going to fail. And let's say that there is a lot of logic,
15:42
a lot of intelligence behind this declaration. You can have in the below in the KEX section, you can have a very low level description. In that case, it's not so nice like the first one because you are executing in that case K exit and this is a full parameter.
16:02
So you are calling K exits with a full parameters, a full list of parameters that are going to send to the minion. You have one guard that is only if, so you have a mechanism to apply to the site if this state can be applied or not. But you can have more intelligence in the state.
16:20
In the right side, you can see that depending of the pillars, certain parameters are going to change. For example, in that case, we are going to inject one extra parameter fat in case that the file system is fat and you are providing some specific flag for this state.
16:42
So you have like different ways of, different levels of abstractions about how to apply the states. Internally, a state is a very complicated beast. Usually, you start validating the input. After that, you make a plan of the actions
17:00
that you need to do in order to fulfill the goal of the state. Sometimes you don't need to do anything because you are reading the final state or stage of the state, so nothing can be done. You also have a test flag that is going to report you. If you activate this flag, it's going to report you,
17:22
okay, I expect that I'm going to do this action and this action, I'm going to change that. So you can inspect what is going to happen before executing or applying the state. Something very cool is that at the end, when he applied a change, recalculate again the actions that need to be done and compare the difference between the current action
17:43
after applying the change and the expectation that he have. And if he find a mismatch, it's going to report that something, I make some change, but the state is not the one that I was expecting. So even if something goes wrong at the end, you are going to understand what change was applied and what element of comparison fails.
18:04
If all the logic inside here goes properly, the state have a very nice property that is potentially he can fix wrong configuration. Because this is a planning and a checking,
18:21
if something goes wrong in a old state, the planning will fix the broken configuration. Not it's always the case, but it's a feature that is sometimes present. So I have a small demo. The demo is a two-node installation.
18:41
Both nodes are going to be different. One of them is going to be a BIOS with a single hard disk. I want to use a swap and I want to have a group partition so you know that in legacy configuration, you need to have a very small partition at the beginning to make room for group. We are going to exercise this requirement.
19:02
Also, the file system is going to be better phase and I want to use this subvolume configuration that we have in OpenSUSE and home is going to be part of the, like is today, is going to be part of the subvolume. In the other node, I'm going to use UFE. It's a secure boot disabled machine,
19:23
so secure boot is going to be there, but it's going to be false. It's two hard disks, one UFE partitions, swap, LVM, so I want to use LVM between both hard disks. For the root, I want to use battery phase, but for home, like in previous OpenSUSE, I want to use extra phase.
19:42
So it's kind of a different configuration. So what I did here is, let me show you that. All the code, by the way, this demo is a small script that is living in my GitHub, a plan as a Yomi demo. As the dependencies are zero,
20:01
it's only one script that is living there. That one is executed, so this one is executed. You're going to have two VMs. Those VMs that you see here are booted using a use base image. It's a normal and classical live use image.
20:24
Inside there, we have the salt minion, and the salt minion is not exactly the upstream one. It's the one that I use for the build-ups. So it's the upstream salt minion together with a very big patch that contain the change that I upstream for Yomi in salt.
20:41
So everything that is in this patch is merged, but not in the release branch, but in the develop branch. So you can see in the terminal here, in the big black one, that I can do a ping. So what I am pinging is the minion that is living in the live, so not the one that is living in the node.
21:01
And I'm going to apply the high state here. So what I'm going to do now is apply the high state. Basically, a high state is like the top configuration from my tree of states. It's a bit hard to explain,
21:21
but basically it's like, okay, I apply all the state that you want to apply for these nodes. There is an asterisk here that means apply for every node that you can find. In that case, we have only two. And there is another terminal that is executing some monitor. So this monitor is a small application that I write
21:43
that is going to read this buffer, sorry, this bus that we saw in the architecture diagram. We are going to read from there every event that is happening there. So let's apply that. Basically, you're not going to see anything here,
22:00
but if everything goes okay, you are going to start seeing some of this log with different colors for each machine. And in the right side, yes, in the right side, you are going to see the state that is going to be applied here, to what is happening in detail there.
22:20
So let's go back to the presentation. This is going to be slow because it's going to download all the package. So this is the real thing that is happening. And let's go back to the presentation, sorry, five. So later we are going to visit the demo again.
22:45
So what is JOMI exactly? Well, JOMI is only a composition of those solved state. It's nothing more. It's a composition, an ordering of those solved state. So each granular element in JOMI
23:03
is a normal and extreme forward solved state. The logic or the complexity in JOMI is how we orchestrate those states. So how we put those states in order in such a way that we are going to guarantee that the proper and the correct state is applied
23:22
depending of the configuration that you want. So in that regard, because JOMI is a solved state, it's a composition of solved state that make JOMI itself an estate. And that means that JOMI can be applied several times without breaking your configuration,
23:42
without breaking your installation. It's going to take care of understanding in which point the configuration fail and continue for that if the complete installation was not complete and detect very early that the installation was done, was done successful and nothing needs to be done after that.
24:04
So this is like a high level abstraction tree of, it's not a tree, it's three layers of abstraction. So JOMI's solved document, it's a SLS document without logic. I mean, without many details of low level stuff
24:25
and all the actions are in the solved stack layer. So in execution models on the state, so that mean that every time that JOMI needs some new feature, some new capabilities that is not possible to be expressed in a solid state or if can be possible to be expressed as a state,
24:43
it's going to be very complicated. A new feature is going to appear in upstream. So the state is going to take care of this new capability or the execution model is going to take care of this flag or whatever. So we can see that JOMI is a very small and thin layer on top of a salt.
25:03
Internally, JOMI is a tree. So all the logic, all the complexity of JOMI is inside this tree shape of a state. So the root of the JOMI is the installer and the first sub-tree that is going to be executed
25:21
is the storage sub-tree and this sub-tree is going to be divided again other sub-tree like the partitioning, rate configuration, volumes, sub-volumes and other key elements that is rate with the storage. If one sub-tree is over, there is another sub-tree
25:41
that is going to take care of the software. So registering the repo, installing the package and taking care of the CS root in order to make sure that all the new software is living in the proper place. After that, we have another sub-tree for users. Another big one for the bootloader
26:01
is going to take care of configuring the bootloader if a snapper is required, taking care that the snapper is properly configured in such a way that Grap is going to show you this menu to recover from all the snapshots. We have some kind of cleaning or post install actions that need to be done
26:21
once that the server is present, once that the user and the service are there. And later, the last one is the reboot or KEX execution. I tried to plot the tree in the right side. This is only a small part of the tree.
26:43
I am a bit old now, so the current tree is a bit more complicated. But with this shape, we are able to extend properly the actions that are missing for a specific installation. So this sub-tree or this tree is only covering the basic stuff.
27:02
If you want to make more complicated configurations during the installation, there are mechanisms to inject your branch in this tree and extend the installer without changing the source code of anything. One lesson that I learned is that
27:22
composability in Sol is a bit tricky. I mean, we can discuss the why it's tricky, but it's very obvious. I mean, it's composing this state that are going to play nice together so when the end of one state is going to be the precondition of the next state,
27:44
maintain this requirement is a bit tricky. Basically, there are some unit's problems, some preconditions are not meet by the post-condition of the previous state. Some exit condition is solved.
28:00
They're not taking care of, that some actions are not real fails or expectations sometimes. So these kind of elements need to be fixed upstream. And part of my job is that all those elements are properly addressed upstream. Yomi can work alone. I mean, you can,
28:22
something very cool that I did for this project is that inject some kind of mechanisms based on macros. So it's kind of transparent for the user and from the developer of Yomi. Some kind of macros that are going to inject certain events in this bus. So it's very easy to inspect what is happening in real time.
28:40
So this previous monitor tool was showing in real time what is happening. And basically, this macro system is, yeah, it's easy to extend and easy to, you can disable that. So if it's somehow making a bit dirty, the output of the installer is something that you can disable if you want.
29:01
But you have a way to control, using salt API, the installation process and monitor it. So it's a way to make sure that Yomi can work, isolate of the installation process, but of course, can work together with the rest of the system. So what is the current state?
29:21
So let me see. Something that we did at the very early of the project is to find a minimal viable product. The MVPs is still ongoing. We are not so far to finish, but we agree that we are going to end this first iteration once that OpenSUSE, MicroOS and SLE are in shape.
29:45
So that means that certain elements are going to be outside the initial scope of Yomi. So if you have a very fancy network configuration, very exotic devices, this is something that you can address, but only using salt
30:02
and only using the extension mechanism that salt provide for you for the installer. What is done? So for storage, it's pretty nice. So we have a GPU, BIOS partitions. We have a way to make very explicit partition schema.
30:23
So you can use the pillars to be very precise of the kind of partition that you expect for your nodes. So if you want to use battery phase in two or three partitions, you can do that. LBN, great, this is done. Something that I have in place is something very cool
30:42
that is a small partition, very similar to the one that provide just, but using a linear programming. So you have this optimization algorithm that if you provide some constraint, it's going to return a solution of those constraints. And you can express the partition problem
31:03
as a set of constraints. So this is a very nice way to have a very deterministic and reliable way of making decisions about sizes and maybe precises. So this is, I have a smaller,
31:21
and there is a three, four slide at the end. If we have time, we can see this algorithm. If not, it's okay. FE, WAFE, FAT 16, 32 is there, it's in place. So you can configure fancy WAFE partitions. X2, X3 is WAFE, but it refers to volume,
31:40
read only, copyright. Snapper, snapshots is there. So snapper is a very nice tool that is going to affect, because it's kind of orthogonal, but it's going to affect not only how you are going to partition, but how you are going to configure for certain bit of software that is very far from the storage. So snapper is completely support.
32:01
You have RAID there over devices and over partition. This is also very tricky to do, because RAID can live on top of raw disks. But if you decide, you can have a pre-partition, write, and partition again over the write. So this is supported. You have LVM.
32:20
You have a UAFE and secure boot available. You have group two. You have the snapshots, software. It's already there. Users, a basic SysConf integration. Something very cool is that you have a full control of chroot. So that means that you have a mechanism now
32:42
in place in sold upstream. It's in develop, not in the release product. To make a full control of your chroot, so you can isolate your chroot, execute any random Python sold state inside this chroot,
33:01
and this state is not going to be able to see outside the chroot. You can, there is a very nice free state that is going to guarantee that you can revert certain installations. So sometimes if you are using chroot, maybe you need some kind of software, but you don't want that. This software is going to be present
33:21
at the end of the installation. You have this free state that is going to guarantee that the amount of software that is going to be leaving in the final stage of the installation is exactly the one that you require, and key exit and reboot is in place. Sold API integration.
33:41
Monitoring is there. Sold reordering of the state, so you have a way to require certain states and guarantee that this tree that we saw in the previous slide is going to be executed in the proper place, and you have a mechanism to inject
34:01
your own state inside the tree. And what is missing? I mean, jazz is a very old product. It has a very long set of features, so going in the same level that jazz is not really easy. It's complicated. So lags or look is not there, so no encryption, because an LVM clash is part of the MVP,
34:22
but it's not present. Resize, resize is an extremely tricky soft thing to do when you are in an attended installation process, so you don't have the possibility that the user is going to inject feedback.
34:40
So making decision about what to resize and if it's okay to resize is going to be tricky, but it's something that we are going to take care. Basic network configuration, this is a shame. The network configuration in upstream for SUSE is not in right shape. We are going to fix that in upstream. We are going to have that in the final version of Yomi.
35:03
We expect to have some basic control XML import, so if you know jazz, for installation, you have a skill CD control XML file that is explaining some constraints
35:20
and restrictions over the installation, so we want some kind of importing this file into your Yomi installation in order to have an equivalent installation for each product. How to jazz converter, multi-architecture is missing, and something that is ongoing for a very long time
35:40
and is my fault that it's not there is the OpenQA integration, but it's going to be there. If you want to follow Yomi, Yomi is an OpenSUSE project, go to the OpenSUSE NME spending GitHub, find it there. You are going to be very surprised, so I hope so, how slim, how small data is there.
36:02
It's only a bunch of SLS documents, YAML, some example of pillars, not much, but nothing else is needed because the real meat is living upstream, so if you go to my OBS, you are going to find
36:22
the version of salt that I'm using. You are going to find there a very big patch on top of our version of salt, and this is where the meat of Yomi is living, and the good news is that it's already in the version of salt.
36:44
It's, I have time, I think, yeah. Yeah, give me one minute, one minute and we can go to the question. So I want to talk about this linear programming thingy because I think that is super cool. So as I told you, making decisions in a reliable way about partitioning is not easy,
37:03
it's not trivial. So if you saw what other guys are doing, you can see that it's a kind of logic in there, but it's very ad hoc, sometimes it's not very clear the rules that finally the software is using to make decisions about the partition.
37:23
And not always, and in the case of partitioning is a very good example, not always, the rules are hard. There are certain points that the rule is extremely hard, so you can't have a very small swap partition if you are expecting to
37:41
froze your machine in those swap. So sometimes the rule is hard, but sometimes the rule is not very hard. So you have some room, some shadow room to move the limits of your decisions. So my proposal here is to use linear programming and express the problem of partitioning hard disk
38:03
as a set of constraint. Constraint that are, some of those constraints are more hard than others. So for example, in this yellow box, we can see a set of constraints. So obviously the sum of all your partition needs to be less or equal than the amount of space
38:21
that you have in your hard disk. And this is a hard rule, but not so hard, because you can have some free space, but you can never have more space in the partition that the hard disk is available to provide. The root partition needs to be between some limits.
38:45
So there is a minimum expectation and maximum expectation. And again, this is not a very hard rule. So the root partition can be sometimes bigger than the one that you put in the max size. And why this is the case?
39:01
Imagine that you have a really partitioned hard disk and the root is there, but it's a bit more big than the one that you have expressed in your control XML. So if you avoid the resize and you meet this criteria that is at least bigger than the minimum, maybe it's not so bad to simply not take the decision
39:25
of resizing or removing and recreating the root partition based on other constraint. Same for swap and home. So you can see that there is a set of logical constraint. So you have an objective function. A linear programming have this constraint
39:41
and an objective function. So the goal is to minimize the objective function. So you have a function that is based on penalization, is going to try to minimize the amount of penalization that you are going to meet if you violate some of those constraints.
40:05
So you can see that if you'd make the decision of resize some present partitions, if you make the decision of not meet the criteria of range for a partition of if you made the decision
40:21
of weight some space, you are going to have penalization, but it's going to be different for each constraint. So the linear programming thing is going to resolve those constraints and provide you a solution. And the good thing is that this solution is always going to be the same. And it's very easy to understand why the algorithm is giving you the solution.
40:42
And the final objective function is going to explain why those constraint is not possible to meet in some case. So if something goes wrong, you are going to see very easily why those constraints cannot meet and why it's better to resolve the hardware problem
41:02
instead of continue the installation. So this is basically what I want to say. And we can see here, this is the monitor tool that I was talking about. So you can see here a lot of states. We can see that those states are so far green
41:21
and the output of salt is that it execute three 16 states. Everything succeed. Something interesting is that the state executing in both nodes are completely different because we make different decisions in both nodes. But we did that with a single command.
41:41
So they take care of making decision, okay, this state makes sense in this node because this pillar and this grains. And we have two VMs here that are available with the user that I create for this matching. So we can see here that in that case,
42:04
we have one hard disk, three partitions. And if I find my place, yep, we can see a different layout here. In that case, we have LVM and on top of LVM,
42:23
we have swap, root, home, and we have two partitions outside. One is FE partition and the other one is the part of LVM. So yes, that's my demo, my presentation,
42:42
and if there are questions. So my first question is about the transaction updates because I know that salt doesn't support yet the microOS system, right?
43:03
Yes, microOS is supported, fully supported. So it's working. Transactional data are there, so you are going to install microOS. I mean, what I was doing my last two weeks is do a full cubic orchestration,
43:23
full cubic orchestration. And one of the step of a full cubic orchestration is installing microOS, is the first step. I said that you need to reboot, execute, cube at the ADM and join the nodes and all the thingy that is for Kubernetes.
43:40
MicroOS is properly installed with transactional update. Yeah, in the same way that jazz is doing, that is the canonical way of doing microOS installation, yes. Also the post configuration of this node does also work with transactional updates. Yes, so yes, this is a good question. I mean, the post configuration is,
44:02
there are several ways of understand post configuration. You have your node with a salt minion. The salt minion come from a live CD or pixie boot. Whatever way, mechanism that you want to inject the salt minion and it's going to be execute in the memory of the node, it's okay.
44:22
You have tons of state that are going to change the hard disk that is physically there and is going to install all the software. But not everything ends there. This is a state that is post install. This post install is going to take care of enable and disable service that the user decide,
44:40
not the package. The user decide what state, because with systemd and chroot, it's possible to enable and disable state. It's possible to configure the network. It's possible to go very far with chroot, of course. It's possible to go very far with an already installed system that you are not booting from there.
45:00
So technically, you can inject the database. You can inject, I mean, if you have a database binary, you can inject that. You can synchronize a lot of information that is going to be ready for the first boot. Not always possible to do after the initial installation. For example, if you are using PostgreSQL, you are going to need, of course,
45:21
the progress service there, so you need to reboot. But all the small details or all the elements that you can advance before the first key exit or reboot is part of this workflow, yes. And do I need to specify something especially on the solid state to specify that I'm going to install a package as?
45:41
Yes, part of my job was to provide a root field inside the state. If you provide that and provide a valid chroot path, this state is going to be executed in this chroot environment. This is working for users, package.
46:02
This is working for systemd. And for any random state that you can apply, if you put that on top of another state that is chroot, so you can think about any random state that you want to be executed inside chroot and you can do that. You can reverse that and this is going to be executed there.
46:21
Another question is about how does the master communicate with the target system if they don't have any operating system yet running? How are you communicating to install the system? Right, maybe I was not clear, but you need to inject in the node a salt minion.
46:40
In that case, in my example, you take a live ISO image and you boot from there. This image contains the salt minion and very small configuration, and a small minion ID configuration and a small auto sign mechanism to set the certificate.
47:02
In this example, it's not there, but in the example of micro OS is there. In the installation image, you can inject again a new salt minion that is going to take over when you reboot because it's salt and you can do crazy stuff. You can take the certificate of the current salt minion
47:23
that the salt master is now able to recognize and inject in the new image. So the next time that the image reboot, the minion is going to be there, master is going to acknowledge the minion and everything goes smooth. Okay, then you say that you can control which packages are going to get started later,
47:42
so you can also configure with Yomi that you have a minimal system. Yes, in this example is the base pattern. For micro OS, you install the three patterns that are expected to be there, whatever you want. What is the shape of that? So I have a small Emacs open here.
48:00
So this is the shape of a salt pillar. So you can see that for this example, there is a section that is software. In software, there is a repository entry and a package entry. In that case, it's very clear what is going to happen. This repo URL is going to be registered inside the CS root and only this pattern and this kernel is going to be installed, nothing else.
48:23
You want something more, change the pillar. And that's all. My last question is about, you say that it's not multi-architecture support yet, only x86 then? Yes, I mean, I don't see any problem, but GRAP needs some tweaks depending on the architecture that you are in now.
48:40
The requirements have to be different. The logic is in place. There is room for this state, but it's not there yet. So yeah. Okay, thank you. Hello, I would like to ask if there is a forward verification.
49:00
I mean, if I have a code for integration, for example, dev as they are free to format to swap and there's nothing like this partition, will it show me immediately when I start the process or in the process? Yes and no. I mean, this is the failed logic of salt.
49:23
So the state, you send a command to the state. In that case, it's create the swap partition. Was not possible to create, you have two option, continue with the next state or fail there. Depending on how you configure the sole master, you have a hard fail and you can decide,
49:40
no, stop here. If you don't have swap, there is no chance of doing anything else. Because I want to break frequently my state and I want to make sure that I can recover from my breakage, I want to continue. So in this example, sole master was taking the decision
50:00
of continue with the state in production. It's expected that this is not going to happen. There is going to be a hard fail and you can do that by a state. So certain fails or certain states are okay, but not for others. So you can put this flag in the state that you think that continue can be helpful because maybe the broken edge is not so hard.
50:22
You are going to have a boot system that you can adapt later. So you can take both decisions. Okay, and second, a little bit tricky. What's the difference between Ansible and Solve? A lot, I mean.
50:40
Sorry about that. Yeah, I mean, with Ansible, you have this master. I mean, you don't have minions, so you have SSH. That means that if you have the certificate recognizing in both sides, you have an open channel that you can send commands. In Ansible, there is not a concept of a state.
51:01
A state is a set of logic step that are going to guarantee that the final result is there or not. And there are some standard mechanisms to validate that. So a state is a guarantee. In Ansible, it's more like a list of execution models in Solve. It's actions that are done there.
51:21
And depending on the quality of the action, some of them are able to understand that something fails and is not idempotent. I mean, sorry, and is idempotent. I don't know how to say that properly in English. But in Ansible, it's not extreme. It's frequent that when you apply a state several times, or, sorry, an action several times, you are breaking more the code you note.
51:44
So there's not kind of logic. So, yeah. Yeah, maybe two additional comments. First of all, because normally the logic is running on the node itself, in this case in RAM, but it could also be in the running system, that's why it's so much faster,
52:01
because there's almost no computation. So all the decisions, oh, you should do five partitions because the pillar says you should SDA one, two, three. All that is already rendered on a client. So you have a lot of compute power. If you have 100 machines installed, you have 100 times your number of CPUs that do all the computation.
52:22
And the server is really just a dump file server that serves you all those config files and a message bus that says, do this. And it's just this one command, salt asterisk, apply high state that is sent over the bus in a broadcast and everyone is listening. Oh, it's an asterisk, so it's for everyone.
52:40
Or, oh, it's mentioning my exact host name or a certain grain I have, like every four CPU server should do this or every server that has SUSE installed. And that makes it so much more efficient. It's also because you have a minion running and there's a concept of things like beacons, which are basically watch talks you can configure. You can send events back to the server at any time.
53:03
Ansible can only talk to the machine when it's talking to the machine, yeah. That's the main difference. And then of course for that scenario, we are using kind of an older version of that approach for retail, for example, for our point of service. You can pixie boot a machine and ask it to say,
53:23
oh, I'm now in a state where you can deploy me and this is the key I want you to accept. With Ansible, you would not be able to do that. You would have to build something else that actually checks, oh, the machine is there so I can SSH into the machine because the machine cannot talk to the server as long as there's no connection established.
53:43
Salt does this. So salt, a minion comes up, it knows, oh, I have to talk to the master that's called mymaster.souza.org and it will try to talk to that master and tell, oh, this is my key. Can you please accept that key? And then you can either have this preaccepted in a whitelist or you can go actually ask the guy
54:02
who booted the machine, okay, can you please check on the screen whether it's the right key? That's kind of the benefit. Well, I have two questions. One is more like from the user point of view and the other is about implementation
54:22
which probably is going to become kind of too long discussion so we'll keep the, well, for the first one, first of all, about being indempotent or whatever is pronounced and that's something we don't have in Autoyast but sometimes I'm not pretty sure if you already have some machines
54:41
and for example, we sometimes specify in our Autoyast profiles that we want a new partition for data, whatever, but we really want it to be new. So we have flags about keeping partitions that are found or recreate them and also about the file system.
55:02
So, but with this indempotent, whatever, approach, it may be that you decide to reuse something that is there and that's not always what we wanted even if it looks like our final partition, same size, same location, we may really want to reformat it
55:22
for just because we want. So I would like to see some example of how that can be achieved. Yeah, I mean, yeah. Sorry, this is a very good question. I mean, there are a lot of level of explaining what is happening. Indempotent is a word
55:43
but let me try to address every level. A word we cannot pronounce, not your name. Too many pronunciations, yes. So you have a mechanism of doing the right thing in the right place. For exactly the use case that you are telling to me,
56:01
I implemented a flag. So there is a very easy way to see if this system was installed by IOMI and was in a successful state. This mark is applied at the end of the installation in the post-installation stage and is checked at the beginning because it's an state, I check that and you don't touch that.
56:20
At the same level, if you want to force the installation of your device, you have another flag that is reformat takeover and this is going to take care of that. So it's a pillar that you say, you know, I don't want to take over. I want to already apply the installation step there
56:46
and be sure that nothing is breakage but there is more there. The question is more deep because this is the concept of ownership of a resource and this is very deep and it's something that is uploading in Kiwi, it's uploading in AutoJAZZ
57:00
and it's uploading in IOMI. It's the ownership of the resource. For example, File System TAP. Who is the owner of File System TAP? Sometimes it's a new package. Sometimes it's an estate. Sometimes it's an execution model. Who is the owner of that?
57:20
So if you add a new line that is going to register slash bar there and later there is a package that is checking that in the case of ETC, micro S is doing exactly that, who is the owner of the line? So ownership is something that affect idempotent
57:40
because you don't want idempotent there because if a package later change this line, you don't want to reset that. So yeah, I need to leave. So this is something, a very deep question and I try to fix that use by use case. Okay, so I guess the other one about the linear programming is out
58:00
so we can discuss it out there. Thank you.