SaltStack Packaging Guide¶
Since Salt provides a powerful toolkit for system management and automation, the package can be spit into a number of sub-tools. While packaging Salt as a single package containing all components is perfectly acceptable, the split packages should follow this convention.
Source Files¶
Release packages should always be built from the source tarball distributed via pypi. Release packages should NEVER use a git checkout as the source for distribution.
Single Package¶
Shipping Salt as a single package, where the minion, master and all tools are together is perfectly acceptable and practiced by distributions such as FreeBSD.
Split Package¶
Salt Should always be split in a standard way, with standard dependencies, this lowers cross distribution confusion about what components are going to be shipped with specific packages. These packages can be defined from the Salt Source as of Salt 0.17.0:
Salt Common¶
The salt-common or salt package should contain the files provided by the
salt python package, or all files distributed from the salt/
directory in
the source distribution packages. The documentation contained under the
doc/
directory can be a part of this package but splitting out a doc
package is preferred.
Since salt-call is the entry point to utilize the libs and is useful for all
salt packages it is included in the salt-common package.
Name¶
- salt OR salt-common
Files¶
- salt/*
- man/salt.7
- scripts/salt-call
- tests/*
- man/salt-call.1
Depends¶
- Python 2.6-2.7
- PyYAML
- Jinja2
Salt Master¶
The salt-master package contains the applicable scripts, related man pages and init information for the given platform.
Name¶
- salt-master
Files¶
- scripts/salt-master
- scripts/salt
- scripts/salt-run
- scripts/salt-key
- scripts/salt-cp
- pkg/<master init data>
- man/salt.1
- man/salt-master.1
- man/salt-run.1
- man/salt-key.1
- man/salt-cp.1
- conf/master
Depends¶
- Salt Common
- ZeroMQ >= 3.2
- PyZMQ >= 2.10
- PyCrypto
- M2Crypto
- Python MessagePack (Messagepack C lib, or msgpack-pure)
Salt Syndic¶
The Salt Syndic package can be rolled completely into the Salt Master package. Platforms which start services as part of the package deployment need to maintain a separate salt-syndic package (primarily Debian based platforms).
The Syndic may optionally not depend on the anything more than the Salt Master since the master will bring in all needed dependencies, but fall back to the platform specific packaging guidelines.
Name¶
- salt-syndic
Files¶
- scripts/salt-syndic
- pkg/<syndic init data>
- man/salt-syndic.1
Depends¶
- Salt Common
- Salt Master
- ZeroMQ >= 3.2
- PyZMQ >= 2.10
- PyCrypto
- M2Crypto
- Python MessagePack (Messagepack C lib, or msgpack-pure)
Salt Minion¶
The Minion is a standalone package and should not be split beyond the salt-minion and salt-common packages.
Name¶
- salt-minion
Files¶
- scripts/salt-minion
- pkg/<minion init data>
- man/salt-minion.1
- conf/minion
Depends¶
- Salt Common
- ZeroMQ >= 3.2
- PyZMQ >= 2.10
- PyCrypto
- M2Crypto
- Python MessagePack (Messagepack C lib, or msgpack-pure)
Salt SSH¶
Since Salt SSH does not require the same dependencies as the minion and master, it should be split out.
Name¶
- salt-ssh
Files¶
- scripts/salt-ssh
- man/salt-ssh.1
Depends¶
- Salt Common
- sshpass
Salt Doc¶
The documentation package is very distribution optional. A completely split package will split out the documentation, but some platform conventions do not prefer this. If the documentation is not split out, it should be included with the Salt Common package.