Groups + States == Awesome!

In my last post I promised to write more about what I’m calling the Groups & States Pattern. We discovered it more or less by accident when we prepared for the SUSE keynote at SaltConf, as we tried to come up with a simple, yet powerful, demo of what you can do with plain Salt states and SUSE Manager.

It’s the answer to one of the most frequently asked questions I’m getting about the Salt integration in SUSE Manager 3:

How can I migrate from my own standalone Salt configuration to SUSE Manager 3 with its built-in Salt?

This picture describes how the usage pattern works:

The Groups & States Pattern

In a nutshell, as a best practice you don’t apply any configuration state directly to a named system, either in Salt’s state configuration files or in SUSE Manager, but always

• assign configuration states to System Groups and only then
• apply your systems to those System Groups

This simple pattern allows for a clear separation of concerns:

• The Salt experts in your organization shouldn’t have to bother with all the systems the configuration templates are applied on. That’s something the admins can do on their own from SUSE Manager.
• The Senior administrators that define the standards can just take the Salt content that the Salt experts have defined, add the necessary “trigger states” to SUSE Manager’s state catalog and then assign them to System Groups.
• Junior system administrators don’t have to know how to write Salt configuration files. While Salt documentation is really well-written, especially the new tutorials, not everyone in your IT organization should need to learn Salt’s YAML state file syntax just to apply a certain configuration template to a system. All they need to do is add systems to the appropriate System Groups and apply the Salt Highstate with the click of a button!

How does this answer the question above? Let me add one more slide from the keynote that Thomas Hatch and Dave Boucha from SaltStack delivered together with me at the openSUSE conference in Nuremberg:

The Power of Three

When we designed the Salt integration for SUSE Manager 3, we created three layers of Salt configuration:

1. The global system defaults under /usr/share/susemanager that are installed as part of installing the SUSE Manager RPMs on the SUSE Manager server. Those are read-only, and only get updated when SUSE Manager is updated. They are always applied and make sure that any system that is managed by SUSE Manager’s built-in Salt Master gets the SUSE-specific signing keys and so on.
2. Configuration in /srv/susemanager that is generated from data in SUSE Manager’s database. This nicely integrates the existing features of SUSE Manager that are now using Salt as the execution engine, like changing and assigning software channels to systems, using the SUSE Manager UI to create package states, or the custom Salt states that you can edit right from the SUSE Manager console.
   For example, the System Groups that you assign to your systems are exported as pillar data to Salt.
3. The default directories that Salt uses, like /srv/salt. That’s where you can integrate your own existing Salt content and make it available to your admins!

We also have three layers for applying Salt states inside SUSE Manager: States defined in SUSE Manager’s state catalog can be assigned to

1. your whole organization (all systems that belong to you)
2. System Groups (that’s what enables the Groups & States Pattern)
3. individual systems

With those cleverly chosen layers you have endless possibilities for applying prepared state definitions to just the systems they should apply to, be it global defaults, groups of systems, or individual overrides for “one of a kind” systems.

In my next post I’m going to talk about extending Salt. I’m also going to blog  about a Hack Week project that my son and I worked on and that could make the Groups & States Pattern even more powerful.

And if you want to see more from SaltConf, check out the talk Don Vosburg and I delivered on SUSE Manager!

This is Joachim Werner blogging live from SUSE in Nuremberg, where we are very concerned about separation of concerns. 😉