Hack Week is over and it’s time to share what we’ve built during these days. In my case, I invested most of my time working with Duncan Mac Vicar in his project to add support for Salt parametrizable formulas to YaST2.
YaST2 CM was born in 2016 as a proof of concept to somehow integrate AutoYaST with Software Configuration Management systems like Salt or Puppet. The idea is that, after AutoYaST has done the main part of the installation (partitioning, software installation, bootloader configuration, etc.), it delegates system configuration to some other tool like Salt or Puppet.
You can read more about how it works in the previous article I wrote about this subject: AutoYaST + Salt et al.
SUSE Manager parametrizable formulas
To get a better insight about SUSE Manager support for parametrizable formulas, you should check Forms are the Formula for Success at SUSE blog. But I’ll try to summarize the most important ideas.
From the Salt documentation:
Formulas are pre-written Salt States. They are as open-ended as Salt States themselves and can be used for tasks such as installing a package, configuring, and starting a service, setting up users or permissions, and many other common tasks.
A good source of examples is the Salt Stack repositories collection at Github.
A key idea to formulas is that they’re intended to be reused, so they are
usually configurable using the Pillar. If you look at the examples, you’ll see
that most of them include a
pillar.example with values to customize.
Parametrizable formulas improve this approach adding the specification of a form that can be used to get the configuration values from the user. Let’s see an example taken from the aforementioned article:
timezone: $type: hidden-group name: $type: select $values: ["UTC", "Europe/Berlin", "US/Mountain"] $default: Europe/Berlin utc: $type: boolean $default: True
Given this specification, it’s pretty straighforward to build a form to get the values from the user and turn them into data that can be included in the Pillar:
timezone: name: Europe/Berlin utc: True
YaST2 CM forms support
Now YaST2 CM is able to use that specification to build a form and get settings from the user. You can check this video to see it in action.
To achieve that, we improved the support for Salt masterless mode. The idea is that YaST2 will download a tarball containing all the needed files and then it will:
- search for form specifications (
- present forms to the user in order to get the configuration parameters
- merge that information into the Pillar
- run Salt in masterless mode
Here’s the corresponding AutoYaST profile fragment:
<cm> <type>salt</type> <states_url>http://myserver.example.net/states.tgz</config_url> </cm>
But what about the tarball layout? Perhaps it will change in the near future, but for the time being it could contain three different directories:
salt/: Salt states (including an optional
formulas/: with all the formulas you want to use. YaST2 CM will search for
pillar/: Pillar data. The formulas configuration will be written to their own files and merged into the (optional)
top.slsin this directory.
And that’s all. Pretty simple, right?
Refactoring and clean-up
During the week, I had the chance to do an important refactor to make the module easier to extend and support. And, by the way, I made some improvements and fixes. I’ll list the most important ones:
- The provisioner runs right after AutoYaST autoconfiguration phase in order to avoid conflicts (for instance, while getting the libzypp lock).
- Instead of trying to unify element names in the profile for all the adapters,
each one uses now its own names. For example, instead of using
config_urlto get states (Salt) or modules (Puppet) when operating in masterless mode, different elements will be used for each adapter:
- Add a
pillar_urlelement to Salt adapter.
- Install correct Puppet packages (using provides information from libzypp).
From my point of view, there are two issues we should solve in a near future:
- Although most of the code is documented, user and some high-level developer documentation is still missing.
- No integration testing. Almost all code is covered by unit tests but, as usually happens in the YaST world, there are several moving parts (including Salt or Puppet servers).
What about Puppet?
To be honest, Puppet adapter needs some love. Formulas are not supported and there’s no plan to do so in a near future. What’s more: it hasn’t been properly tested and I have to find out whether it is still working after recent changes.
Of course I’ll find some time to invest on it but having some extra help would be great. So, if you’re interested, just ping me!
YaST2 CM is still a young project and there’s a lot of work to do. I would like to continue adding new features and fixing bugs. And, of course, getting some feedback would be really great!
So if you’re interested in contributing (testing, documenting, writing code, etc.) just let me know.