Deploying Salt:
- How to make minions aware of other minions. Cross-minion configuration.
- Proper ordering of salt states (i.e. Repo.highstate -> base.highstate -> manual stuff -> *.highstate)
Updating configurations:
- Merging new pillars during an RPM update.
- Adding/deleting minions from "inventory", handling configuration updates in other minions automatically
- A/B rollout of new configuration
Before I suggest adding any additional dependencies to the current deployment, I'll note that most of these problems can be addressed using some of Salt's advanced features:
- Sharing configuration details across minions can be accomplished using salt mine or peer communication
- Proper ordering of salt states can be done by the Salt orchestrate runner
- (Re)executing states automatically in reaction to added/deleted/updated/failed minions can be done using Salt's reactor in conjunction with events from the presence system
- A/B rollouts can be achieved through use of environments
As far as I can tell, there is no direct solution to the problem in merging pillar configurations during an update. A third party tool would have to be used to create the translation. I imagine it would be best to have a single source for configuration that could be easily translated into the various pillars. This translator could be packaged in your RPM along with the pillar files and used to regenerate pillars during updates.
Sigma is service dependency framework with the ability to execute arbitrary code to deploy, monitor, update, or delete services running remotely. Sigma has the built-in capability to track the relation between multiple services, automatically react to updated configurations, and deploy pillar states.
To translate the current salt deployment to sigma, we would create a series of interrelated services that would manage the deployment and configuration of both salt and OMD services.
- Salt Master: Deploy and manage salt master and minions
- Salt Pillars: Depends on Salt Master. Manage salt pillars available to salt master. This is single source of configuration that creates and maintains the variety of pillars needed by the OMD services
- OMD Services: Depends on Salt Pillar. Manage deployment of OMD services via Salt. Apply states in proper order, react to changes in pillars that require reconfiguration
Note, it would be possible to further decompose "OMD Services" to reflect any additional dependencies that are important.
The dependency-driven structure of Sigma handles the problems of updating services organically. Any changes to configuration, removal or addition of minions, etc, will be handled automatically by Sigma's state machine.
Sigma services encapsulate the logic to ensure states are executed in the proper order everytime, with the ability to procedurally react to errors along the the way.
Has the side effect of possibly making the initial deployment of salt minions easier. The Salt Master plugin can be written in such a way that no custom-built ISO will be required to bootstrap minions remotely. Just install sigma, add the Salt Master service, and hit go.
Have to install, maintain, and debug an additional service (Sigma).
Using Sigma requires a few new artifacts. Each service requires a "plugin" which outlines the required configuration for a service, and a docker container that encapsulates the logic to deploy, monitor, update, and destroy the service. These would have to be built, maintained, and distributed in your regular release cycle.
Encapsulation of the logic of managing Salt inherently makes in-place modifications to salt harder. It would become more difficult to modify salt scripts and pillar data once the service is deployed.
Sigma doesn't (currently) have any features for A/B rollouts. Any configuration changes would (currently) result in mass-reconfiguration of affected services.