Last week, on the first day of OpenWorldForum 2013, we met up with
Thomas Hatch of SaltStack to have a talk about salt. He was in Paris
to give two talks the following day (1 & 2), and it was a
great opportunity to meet him and physically meet part of the French
Salt community. Since Logilab hosted the Great Salt Sprint in Paris, we offered to
co-organise the meetup at OpenWorldForum.
About 15 people gathered in Montrouge (near Paris) and we all took
turns to present ourselves and how or why we used salt. Some people
wanted to migrate from BCFG2 to salt. Some people told
the story of working a month with CFEngine and meeting the same
functionnality in two days with salt and so decided to go for that
instead. Some like salt because they can hack its python code. Some
use salt to provision pre-defined AMI images for the clouds
(salt-ami-cloud-builder). Some chose
salt over Ansible. Some want to
use salt to pilot temporary computation clusters in the cloud (sort of
like what StarCluster does
with boto and ssh).
When Paul from Logilab introduced salt-ami-cloud-builder, Thomas
Hatch said that some work is being done to go all the way : build an
image from scratch from a state definition. On the question of Debian
packaging, some efforts could be done to have salt into
wheezy-backports. Julien Cristau from Logilab who is a
debian developer might help with that.
Some untold stories where shared : some companies that replaced
puppet by salt, some companies use salt
to control an HPC cluster, some companies use salt to pilot their
existing puppet system.
We had some discussions around salt-cloud, which will probably
be merged into salt at some point. One idea for salt-cloud was raised :
have a way of defining a "minimum" type of configuration which translates
into the profiles according to which provider is used (an issue should
be added shortly). The expression "pushing states" was often used, it
is probably a good way of looking a the combination of using
salt-cloud and the masterless mode available with salt-ssh. salt-cloud
controls an existing cloud, but Thomas Hatch points to the fact that
with salt-virt, salt is becoming a cloud controller itself,
more on that soon.
Mixing pillar definition between 'public' and 'private' definitions
can be tricky. Some solutions exist with multiple gitfs (or
mercurial) external pillar definitions, but more use cases will drive
more flexible functionalities in the future.
For those in the audience that were not (yet) users of salt, Thomas
went back to explaining a few basics about it. Salt should be seen as
a "toolkit to solve problems in a infrastructure" says Thomas
Hatch. Why is it fast ? It is completely asynchronous and event
He gave a quick presentation about the new salt-ssh which was
introduced in 0.17, which
allows the application of salt recipes to machines that don't have a
minion connected to the master.
The peer communication
can be used so as to add a condition for a state on the presence of
service on a different minion.
While doing demos or even hacking on salt, one can use
salt/test/minionswarm.py which makes fake minions, not everyone has
hundreds of servers in at their fingertips.
Smart modules are loaded dynamically, for example, the git module that
gets loaded if a state installs git and then in the same highstate
uses the git modules.
Thomas explained the difference between grains and pillars : grains is
data about a minion that lives on the minion, pillar is data about the
minion that lives on the master. When handling grains, the
grains.setval can be useful (it writes in /etc/salt/grains as yaml,
so you can edit it separately). If a minion is not reachable one can
obtain its grains information by replacing test=True by cache=True.
Thomas shortly presented saltstack-formulas : people want to "program"
their states, and formulas answer this need, some of the jinja2 is overly complicated to make them
flexible and programmable.
While talking about the unified package commands (a salt command often
has various backends according to what system runs the minion), for
example salt-call --local pkg.install vim, Thomas told this funny
story : ironically, salt was nominated for "best package manager" at
some linux magazine competition. (so you don't have to learn how to
use FreeBSD packaging tools).
While hacking salt, one can take a look at the Event Bus (see
test/eventlisten.py), many applications are possible when using the
data on this bus. Thomas talks about a future IOflow python module
where a complex logic can be implemented in the reactor with rules and
a state machine. One example use of this would be if the load is high
on X number of servers and the number of connexions Y on these servers
then launch extra machines.
To finish on a buzzword, someone asked "what is the overlap of salt
and docker" ? The answer is not simple, but Thomas thinks that in the
long run there will be a lot of overlap, one can check out the
existing lxc modules and states.
To wrap up, Thomas announced a salt conference
planned for January 2014 in Salt Lake City.
Logilab proposes to bootstrap the French community around salt. As the
group suggest this could take the form of a mailing list, an irc
channel, a meetup group , some sprints, or a combination of all the
above. On that note, next international sprint will probably take
place in January 2014 around the salt conference.