We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Adding Salt to AutoYaST

00:00

Formal Metadata

Title
Adding Salt to AutoYaST
Subtitle
Integration between AutoYaST and Configuration Management Systems
Title of Series
Number of Parts
57
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
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
YaST2 Configuration Management is a brand new YaST module which offers integration between AutoYaST and Salt. It's no secret that many AutoYaST configuration features can be implemented using some Configuration Management System (like Salt or Puppet). So the idea is to bring together the best of both worlds: AutoYaST will take care of installing the base system (partitioning, networking, etc.) and Salt will configure the system. During this talk, attendees will see the module in action and will get into the nitty-gritty details as well. Of course, we'll also have a look at experimental features, like Puppet support or SUSE Manager Salt Formulas integration. Last but not least, we would love to hear more ideas from you and discuss your use case.
55
Thumbnail
26:08
Configuration spaceMaizeSoftware developerModule (mathematics)INTEGRALInformation Technology Infrastructure LibrarySystem programmingData managementEndliche ModelltheorieComputer animationUML
Installation artSystem programming
System programmingConfiguration spaceSoftwareComputer networkService (economics)Partition (number theory)Scripting languageUser profileMaizeEncryptionModul <Datentyp>Distribution (mathematics)Module (mathematics)CASE <Informatik>Service (economics)Profil (magazine)SoftwareClient (computing)Configuration spaceMoment (mathematics)Limit (category theory)Selectivity (electronic)System programmingScripting languageFluid staticsComputer fileDescriptive statisticsEmbedded systemComputer configurationDifferent (Kate Ryan album)RootkitInformation Technology Infrastructure LibraryInclusion mapDistribution (mathematics)MereologyModule (mathematics)NeuroinformatikRational numberWorkstation <Musikinstrument>Observational studyWritingACIDMobile appLine (geometry)Entire functionPartition (number theory)Data storage deviceAdditionPosition operatorProcess (computing)Computer animation
Configuration spaceSystem programmingSystem administratorComputer configurationEvent horizonData managementArchitectureLibrary (computing)Component-based software engineeringState of matterWell-formed formulaRootkitLocal GroupAsynchronous Transfer ModeObservational studyNeuroinformatikSystem programmingMoment (mathematics)MathematicsState of matterData managementInformation Technology Infrastructure LibrarySystem administratorSoftwareProcess (computing)Directory serviceServer (computing)Configuration spaceMechanism designDescriptive statisticsRemote procedure callComputer configurationInstallation artInformationPower (physics)Service (economics)Correspondence (mathematics)Range (statistics)Address spaceIP addressPresentation of a groupConnectivity (graph theory)Library (computing)Electronic mailing listWeb 2.0Open sourceSelectivity (electronic)Interpreter (computing)Well-formed formulaDatabase normalizationVirtual machineDifferent (Kate Ryan album)DemonComputerUltimatum gameSensitivity analysisRational numberGroup actionSlide ruleCellular automatonComplete metric spaceWebsiteLevel (video gaming)Arithmetic mean1 (number)Computer animation
Decision theoryLine (geometry)Information Technology Infrastructure LibraryDefault (computer science)Computer hardwareSystem programmingService (economics)Sensitivity analysisModule (mathematics)Goodness of fitObservational studyOnline helpRational numberNeuroinformatikSoftwareMachine visionSet (mathematics)
Computer networkSoftwareConfiguration spaceService (economics)Key (cryptography)Group actionConvex hullCASE <Informatik>Key (cryptography)Server (computing)Open sourceSystem programmingProfil (magazine)Regular graphPublic-key cryptographyService (economics)Point (geometry)Message passingInformation Technology Infrastructure LibraryComputer configurationScripting languageVideoconferencingMultilaterationAuthenticationAdditionState of matterSoftwareDemo (music)Complex (psychology)Configuration spaceModule (mathematics)Sheaf (mathematics)Observational studyVideo game consoleRight angleMoment (mathematics)Different (Kate Ryan album)INTEGRALView (database)Data management2 (number)Rational numberNeuroinformatikInformationSet (mathematics)Computer animation
System administratorSystem programmingAsynchronous Transfer ModeServer (computing)State of matterModule (mathematics)Local area networkCASE <Informatik>State of matterConfiguration spaceSystem programmingData storage deviceOrder (biology)InformationKey (cryptography)Asynchronous Transfer ModeTurbo-CodeModule (mathematics)Computer animation
Computer networkMechanism designTime zoneLocal GroupBoolean algebraGroup actionMereologyWell-formed formulaState of matterField (computer science)Software testingBoolean algebraHacker (term)System administratorVideoconferencingSystem programmingModule (mathematics)User interfaceInformationWeb applicationTime zoneMultiplication signDefault (computer science)Parameter (computer programming)Descriptive statisticsInstallation artRevision controlComputer fileGame controllerDifferent (Kate Ryan album)CodeLine (geometry)Message passingData managementTouchscreenSoftware developerSelectivity (electronic)Form (programming)outputBlogFood energyBitEndliche ModelltheorieInheritance (object-oriented programming)File formatInsertion lossStaff (military)MetreCuboidComputer animation
Group actionCASE <Informatik>HypothesisComputer animation
DisintegrationCloningINTEGRALWell-formed formulaInformationInstallation artMultiplication signSystem programmingModule (mathematics)TowerEndliche ModelltheorieGame theorySpeciesView (database)Computer animation
Commodore VIC-20Module (mathematics)Endliche ModelltheorieBitMereologyModule (mathematics)InformationProjective planeData managementPoint cloudDatabase normalizationOnline helpRight angleComputer animation
DebuggerLevel (video gaming)Data managementE-learningWebsiteSoftware frameworkForm (programming)Well-formed formulaMultilaterationDatabaseState of matterMultiplication signParameter (computer programming)Web pageMereologyLebesgue integrationVideoconferencingNetwork topologyLink (knot theory)Goodness of fitFront and back endsGame controllerWeb 2.0Slide rulePassword
Time zoneLocal GroupBoolean algebraINTEGRALTime zoneModule (mathematics)SoftwarePoint cloudCASE <Informatik>MereologyLine (geometry)System callData managementMultiplication signCodeElectronic mailing listSoftware frameworkExistenceBijectionCuboidComputer fileDrop (liquid)Computer animation
Cartesian closed categoryHypermediaComputer animation
Transcript: English(auto-generated)
Well, my name is Simovac. I joined SUSE around two years ago, just to work on AutoJAZZ. And today I'm here to present you our brand new module, our brand new JAZZ module that
offers some kind of integration between AutoJAZZ and configuration management systems like Zold. First of all, I would like to start speaking about AutoJAZZ. How many of you know
about AutoJAZZ or use AutoJAZZ? Quite some people, so I cannot lie. So the idea behind AutoJAZZ, it's a tool that allows us to perform unattended installations or system upgrades. It also allows us to perform automatic configuration of already installed systems.
It's not the most common use case, but it's also something that is possible with AutoJAZZ. It will take care of partitioning, network configuration, software installation. If you
are using SUSE, it will take care of registering the system and all that stuff. And it's also able to configure additional services like you can install, for example, an HTTP server, an NTP client or whatever. So it performs the basic installation and also it's able
to configure and install additional services. That's the main idea behind AutoJAZZ. The idea is pretty simple, well not simple. You write a description of the system you
want to install. This is an XML document that defines some sections. There are a lot of sections, these are some of them. Partitioning, the partitioning layout that you want to use.
Software selection, if you want to install some patterns or whatever. Networking configuration, static configuration, how many devices or a lot of things. You can also run scripts in different moments of the installation. You can also write configuration files. So
you can do a lot of things with AutoJAZZ. I like to see AutoJAZZ as part of JAZZ, so it just takes that profile and drives JAZZ to make the installation that you have
described in this document. But I think one thing that I like about AutoJAZZ is that you don't need to specify a lot of configuration options. With this profile that JAZZ setups a root user that you can also omit some configuration. But with that setup it will
take care of partitioning your system, configuring the software selection and all that kind of stuff. So you don't need to specify everything. After all it's just part of JAZZ, so it will just behave like JAZZ when it comes to defaults, selections
and all those things. When you want to write a profile you can create one from scratch, copy and paste them from the documentation, copy and paste them from other profiles or just writing your own. And you also have an AutoJAZZ UI that allows you to inspect
the running system and to tweak some parameters and generate a profile from the installing system that we call clone system. And you also have a command line that you just run it creates a configuration that looks like your running system and you can adjust it.
Or you can just create your profile programmatically. You generate a profile that you fed later to AutoJAZZ. But to be honest we have some limitations with AutoJAZZ because the use case was not to cover all the configuration management
thingy. So it's limited to JAZZ modules. I mean we don't have a module to manage Redis or to manage PostgreSQL and we don't want to have those modules. So, in those cases AutoJAZZ enables you to create that configuration by writing embedding
configuration files or scripts in the profile. But to be honest when configurations or setups are complex that's maybe not the way to go.
Also, another problem is that when you clone a system installation is not always 100% reproducible. If you configure something outside AutoJAZZ of course that won't be in the profile. But even if you use a script in your profile when you clone the system that script won't
be included. So you need to do it manually. It only applies to OpenSUSE and SUSE distributions. That's somehow a limitation. So, let's put AutoJAZZ down for a moment and talk about configuration management software. Configuration management software enables the administrator
to configure and track changes in the infrastructure. Usually the administrator creates some kind of description. It depends on the system, how the system should look like. The system
will take care of installing packages and all that stuff. It's not that magical. It needs some work. But it's pretty good because the deployment is automated and always reproducible. In that case, those tools do a great job. In the open source community we have a lot
of options with a wide range of features from salt, which is a complex system, even driving and has a lot of features, to things like Capistrano. It's quite narrow and it only
does one thing, but it does very well. But here at SUSE we are pushing for salt. Salt, as the previous speaker told, is not only a configuration management system, but it also has a remote execution engine, so you can run arbitrary commands on remote
systems and it also has a pretty powerful selection mechanism to select which commands should be running which system. It's even driving. I must admit that I hadn't seen the talk from Thomas before waiting for my slides, but I will highlight that it's even
driving. It's a pretty flexible architecture. You can use a master server to get the configurations to the agents. You can get rid of the master server and use some kind of standalone configuration. Or you can get rid also of the agents and just configure the system
using SSH or something like that. So you have many options. It has pretty good documentation, in my humble opinion, and they have an interesting library of reusable components. We'll say
something about that in this slide. I'm going to oversimplify things a lot, but I want to show you some concepts that we're going to see when running the example. We could say that it's more complex, as I have said, but we could say we have two different roles.
We have the master machines that are the machines that say to the system that we want to manage what they need to do. We have the minions, which are the systems that we are managing. Usually they have installed a daemon and instructions from the master. We
have the concept of a state. A state is a description of what do you want to do with that system. For example, I want to install Apache web server. You need to install this package. You need to run this server. You need to write this configuration file. That's
how the information is used in the state, the configuration data, sensitive data. For example, if you are installing the HTTP server, you can have in the pillars the list of hosts with the MAC addresses and IPs and the correspondence. And then the state will
take that information from pillars and it will configure the machine according to that information. So we come to formulas. Formulas are reusable states. Usually they can interpret information from pillars. So you, for example, can use a formula to install a PostgreSQL
server and you define a pillar. In your pillar you define some options so you can set a different port, a different directory for data or whatever. You can configure somehow the state. And finally we are not going to see grains again during this presentation
but just for the sake of completeness, grains is data associated to those agents, to those minions. Usually it's information from the underlying systems but you can also set the Keystone grains on minions. So you have here a simple example. Details are
not that important. It's a state to install an Apache server, to install a package, to make sure that the service is running and you write the configuration file. It's not that important, just take the general idea.
So if you have been paying at ACM you maybe have found some kind of redundancy between salt and autoyass, right? Yes. So the idea of this module is to get the best
of both worlds. On the one hand we would like autoyass to make the initial installation because it just makes some interesting decisions and helps to have a good installation with
sensitive defaults and that kind of stuff. And it's also able to install on hardware without any system, installing the base system. But when it comes to configuring additional services we are doing the same, autoyass and salt, salt and other configuration management
systems. So the idea would be maybe to draw a line and leave autoyass to make the initial installation, initial software selection, network configuration if needed, partitioning
all that stuff will be done by autoyass. And salt will perform the installation and configuration of additional services. We know that we have at SUSE some people that use some kind of a script to download some state and do it by hand. So we felt that we should offer an option so they can use
autoyass and configuration management systems in an easy way. So this is a snippet from an autoyass profile. We tried to find a shorter name which was
meaningful and without using acronyms but it was almost impossible. So you have configuration management section. We are saying that we want to use salt because we'll see later
that we support another system on some kind of experimental feature. We want the system to connect to that master and we want to use the authentication keys that are in that HTTP server. It's cool because you can have your authentication keys, use
a public and private key in your pen drive and plug it into the system and it will search if you select USB device it will search for authentication keys in your device.
And also authentication keys are stored with the name of the hostname so you can save many of them in the same place. In this case those keys should be accepted in the master server but in this case they are pre-accepted which is a use case for salt.
I'm not going to do a demo because it's only half an hour and things can go wrong so I just recorded a video and will check the video just to prove that it works.
So I'm going to stop for a moment. At this point JAS has already done the installation of packages, has configured the network and all that stuff. The only remaining step I think is the bootloader and with the configuration the module had installed the
salt packages during regular software installation, have retrieved keys and copied them to a special place so salt can find them and it also has updated salt configuration so when you restart the system salt is properly configured to be registered without SaltMaster.
You have a pop-up with a lot of debugging information, the salt running. This state that I'm using here is pretty simple. It's just only about changing the message
of the day. We'll see a more complex example later. We have changed the message of the day from the open source system and we just fast forward
and it's changed. So it works. We have other possibilities when configuring salt.
For example, maybe we don't want to have the pre-accepted keys then in that case we can specify some kind of timeout and the system will try to connect to the SaltMaster and we accept, as administrator, accept the key and it will retry later in order to get
the configuration. And another way to use this module is masterless mode. Maybe you don't need a SaltMaster in this case. You just have your states in a turbo. You have your pillars data in another turbo and you say okay, I'm not going to use a salt,
I just want to use this state with this information and it will take care of installing salt, running salt with that information and configuring your system as easy as that. So I think that this one is the more interesting part, experimental features where the first
one is about Puppet. We support Puppet. When we started to write this module we wanted to support more than one system just to make sure that it's flexible enough to add
support for more stuff if we need. Puppet support is not that tested so maybe it's not supported yet at this time. During the last Hack Week, Dakham Bambikar and me were
working in SUSE Manager Parameter-Sable Salt Formulas support. So these lines of code is a YAML file. I have taken an example from Joaquin from his blog post. I have
data from a pillar so we have data for the time zone. The name of the time zone is Atlantic Canary. We want to use UTC. That's pillar data. SUSE Manager Parameter-Sable
Salt Formulas allows the developer to build a user interface to get that information in a handy way for the administrator or the user. The idea is that you have a description
like this one where you say, okay, I have two parameters for this pillar. I have a name of the time zone with some values and I have a default value. And I also have
another field which is called UTC and with some default value. It's a boolean. That's fine. And with that information you build this form. So you have a form in a web application with the name and the UTC fields. The administrator can fill those
controls and it will be written to the pillar and used when deploying the system. So we have support for something like that in this module. If the module finds that
some of the formulas you are using has this kind of description it will bring a user interface so you can put the values that you want and the system will be installed with those values. So let's see another video. The state I'm using here, the state
also changes the method of the day. It uses a test formula with a lot of fields so you can see the different kinds of controls that you can define. It also installs some
packets and some more things just to prove that we can install packets with Zipper and other things. We have found two formulas and both of them contain some information.
We are going to check both of them because we can apply and tweak both of them. So that guy is going to move the screen a little bit, checking, browsing for the different options, nothing interesting at all. But you can see that we have different controls,
input select boxes, text fields, booleans. We are going to change the message of the date here by hand. It is not written in the pillar yet. And now the module will take care of merging that information and deploying the system. For example here it is running
Zipper. In the first version Zipper didn't work. And now you have the message updated. So that's it. Okay. So let's close this. The future. The future. The future.
I must say that I would love to use use cases because we have gathered some use cases and if you are at the conference at the end we will stay around so just tell us
if you want some use cases that you would like to be supported. Some wild ideas. None of those wild ideas is going to become a reality any time soon. Or maybe any time. For example
I think what we need to do is to improve the integration with the installer because you get an ugly pop-up with a lot of information running. We should include that information not in a pop-up but in the installer itself. It should look nicer.
Support in the autoyask UI because in the autoyask UI you cannot specify any value for salt or something like that. Maybe cloning support. It's a little bit tricky but maybe we will try to add cloning support. Supporting Jira for puppet because it's the only missing piece for this module to be for this adapter to be somehow complete.
Maybe support for Git so you don't have to use tarballs. Git is not available in the installation system but it's available in the install system so maybe we can make it. Even the formulas is not a finished feature because we are not sure if we should
put it at the end of the installation at the beginning. If you put the formulas at the beginning then you need to do some work in advance. There is a feature request but it's not finished.
Finally, I would like to thank some people. First of all my beloved JAS team because the module was born last year in a cloud internal workshop at SUSE. But the JAS team
has adopted the module. It's now the official part of JAS and we are all taking care of this module. To Danke MacVicar for his contributions and help to know a little bit more about salt and that kind of stuff.
Hannes Kunhemum because when I first joined SUSE I found out when I was working with AutoJAS that kind of redundancy I was talking about before. I talked to my manager and my manager said okay, let's write a feature request. Let's put it down, write
it down so we can discuss about that. I didn't in the following weeks but I found out that someone did it for me. So there was some discussion and the failure request was already there so I had some information to start working on. And of course to the
OpenSUSE project for giving me the opportunity to present our new module to you this morning. I think that's all. If you have any questions please.
Is it working? Yes. So there were some nice videos that looked good. One question that came to me was, is it also working with nCurses? Yes, it works with nCurses. There is a video. I can paste you a link later on the slides
and there is a video of the formulas running on nCurses. You have to manage to have too many levels, too many controls in the same page because it is a tree. But with the tree we can do it well. Thanks.
Thank you so much for driving this. Just for everyone who is not quite familiar with the overarching idea I have behind this whole formulas with forms, the cool thing about this is that the same framework is also working in the web front-end in SUSE Manager. So let's say you have just created a very new NoSQL database. Not because there
aren't enough yet. And you want to make sure that people can set up the 10, 15 parameters that you have to set up to configure a database. You just write a salt state, put it into a folder, then it's a formula. You write this form which is basically just annotated
YAML where you say, okay, this is a password. This is a drop-down and those are the values. And then you have a YAS module and you have integration in SUSE Manager and you can run it on the command line as part of your solder-ons. That's really the great new thing that for
the first time you have a framework that spans one-to-one YAS installation where people sit in front of a UI down to fully automated rolling this out in the cloud on thousands of nodes with one framework. That's really the cool thing. Now for crazy ideas, the last thing that came to my mind that would make this really
cool is that currently, let's say you have this values box here, you have to provide those values in this drop-down. But if we had a callback where we just put a line of salt code in there that says look at the box and grab whatever, I don't know, let's say
network devices are on the box or in that case read the existing time zones file and give me all the time zones that you can actually configure, that would of course be very cool. And I think it would be possible the way the framework is set up because you can just,
when the code is running, call into salt and return a list of stuff that you then feed back into the UI. We'll try. So if there's no more questions, you have one minute left to make whatever
you want. Thank you.