I need some perspective on how to implement a versioned minion state so
that 'highstate' calls don't deploy new components until told explictly to
We are building a ThoughtWorks GoCD setup to handle continuous deployment.
In GoCD, every deployment pipeline run is versioned and utilizes versioned
artifacts or materials (e.g., war, jar, RPM, properties, settings, etc.) as
part of that version of the pipeline.
This served as our "rollback" plan at my previous company. If something
failed when deploying a newer version, we could simply go back and re-run
the last successful pipeline and it would deploy using the exact same
artifact versions previously used.
I was hoping to do something similar at my current job using SaltStack.
Our initial implementation is currently moving toward the *master-minion*
model with *GitFS *managing our states/pillars.
Is it possible to associate a particular revision (or commit) of my salt
states/pillars with a minion so that until told otherwise, it uses that
version of pillars/states?
Let's say I have tomcat server in each of our dev, qa, stage and production
environments, the version of the WAR file in production might be version
1.0, but dev might be up to 1.2.15 and stage may have 1.0.2. I would like
to make it so that running 'state.highstate' would not change anything
until told to use different state/pillar versions.
So if the current version of our application state in 'dev' is based on:
- github.com/myrepo/salt-states commit
- github.com/myrepo/salt-pillars commit
It would be interesting if I could somehow set a persistent revision of the
state I want a given minion to use, such as:
#> salt 'tomcat-dev01' state.revision
#> salt 'tomcat-dev01' state.highstate
This would lock a minion to a specific revision. The GoCD pipeline could
then archive the commit versions that were used on a per-pipeline basis
allowing me to set a minion to any version of any state. I'm not sure of
the mechanics, especially if there are multiple repositories involved.
Has anyone done something like this with a similar setup
(master-minion+gitfs)? I suspect that I may have to go masterless if I
want to really be able to tie GoCD pipeline revisions to a version of the
salt states). However, I don't want to abandon the master-minion model as
I still want to be able to push critical updates and do monitoring among
See my LinkedIn profile at:
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.