SUSE Manager 3.2 › Best Practices › Configuration Management with Salt

5 Configuration Management with Salt

5.1 Configuration Management Overview
5.2 State Data
5.3 Salt States Storage Locations
5.4 SUSE Manager States
5.5 Pillar Data Exposed by SUSE Manager

5.1 Configuration Management Overview #

Salt is capable of applying states by matching minions with relevant state data. This data comes from SUSE Manager in the form of package and custom states.

5.2 State Data #

State data comes from SUSE Manager in the form of package and custom states and targets minions at three specific levels of hierarchy. The state hierarchy is defined by the following order or priority: individual minions have priority on packages and custom states over groups; next a group has priority over the organization.

Minion Level
Systems › Specific Minion › States
Group Level
Systems › System Groups
Organization Level
Systems › Manage System Types: › My Organization

For example:

Org1 requires that vim version 1 is installed
Group1 requires that vim version 2 is installed
Group2 requires any version installed

This would lead to the following order of hierarchy:

Minion1 part of [Org1, Group1] wants vim removed, vim is removed (Minion Level)
Minion2 part of [Org1, Group1] wants vim version 2 gets version 2 (Group Level)
Minion3 part of [Org1, Group1] wants any version, gets version 2 (Org Level)
Minion4 part of[Org1, Group2] wants any version, gets vim version 1 (Org Level)

5.3 Salt States Storage Locations #

The SUSE Manager salt-master reads its state data from three file root locations.

The directory /usr/share/susemanager/salt is used by SUSE Manager and comes from the susemanager-sls. It is shipped and updated together with SUSE Manager and includes certificate setup and common state logic to be applied to packages and channels.

The directory /srv/susemanager/salt is generated by SUSE Manager and based on assigned channels and packages for minions, groups and organizations. This file will be overwritten and regenerated. This could be thought of as the SUSE Manager database translated into salt directives.

The third directory /srv/salt is for custom state data, modules etc. SUSE Manager does not operate within or utilize this directory. However the state data placed here affects the Highstate of minions and is merged with the total state result generated by SUSE Manager .

5.4 SUSE Manager States #

All sls files created by users will be saved to disk on the salt-master server. These files will be placed in /srv/susemanager/salt/ and each organization will be placed within its own directory. Although these states are custom, these states are created using SUSE Manager . The following provides an overview of directory structure:

├── manager_org_DEVEL
│   ├── files
│   │    ... files needed by states (uploaded by users)...
│   └── state.sls
         ... other sls files (created by users)...
E.g.:
├── manager_org_TESTING
│   ├── files
│   │   └── motd     # user created
│   │    ... other files needed by states ...
│   └── motd.sls     # user created
            ... other sls files ...

5.5 Pillar Data Exposed by SUSE Manager #

SUSE Manager exposes a small amount of internal data like group membership, organization membership and file roots as pillars which can be used with custom sls states. These are managed by SUSE Manager or by the user.

To avoid hard-coding organization id’s within sls files, a pillar entry is added for each organization:

org-files-dir: relative_path_to_files

This file will be available for all minions which belong to this organization.

The following represents a Pillar example located in /etc/motd :

file.managed:
    - source: salt://{{ pillar['org-files-dir']}}/motd
    - user: root
    - group: root
    - mode: 644

Print this page