We had problems with salt not being reliable. Across 1200 nodes, we would get
too many that would just fall to execute the change we wanted it to execute. On
each run of the same change we'd get different nodes that worked each time. As
we have a solid puppet system for configuration management & only were using
salt as a "do this" tool, we switched to ansible for those tasks & removed salt
from our environment.
On March 31, 2015 9:26:55 AM CDT, Atom Powers <atom.pow...@gmail.com> wrote:
>That was my comment, based on limited use of Salt. I've now been using
>Salt in production for about three months (new job) and I would make
>the same comment.
>
>Salt states can, theoretically, do everything Puppet can do. In
>practice I find that the ecosystem around Salt states is very thin. I
>find it difficult to locate states that other people have developed
>and those are usually not general enough for me to use without
>modification. I haven't found many good examples of Salt states or
>documentation about how to write testable and generic states for Salt;
>something Puppet has a strong ecosystem around. Some things that
>Puppet does easily like parameterized classes, hiera, and collected
>resources are things that seem to be missing or difficult to implement
>in Salt.
>
>I like Salt and I like the /idea/ of Salt as an OSS configuration
>management platform. I think Salt will always lag behind Puppet in
>some ways. In other ways Salt is way ahead of Puppet, especially with
>cloud provisioning and making changes based on the current/changing
>states of other systems.
>
>I would use Salt to bootstrap a system and Puppet/CfEngine to maintain
>state on that system. The right tool for the right job.
>
>On Mon, Mar 30, 2015 at 9:27 PM, Leon Towns-von Stauber
><leo...@occam.com> wrote:
>> Resurrecting this thread because I have a question. We use CFEngine 2
>at my current shop, and are now evaluating CFEngine 3 and Salt as
>replacements. I was hoping to get clarification on this comment:
>>
>>> I would use Salt when I need to build full application stacks
>>> including many dependent types of systems, and don't need to manage
>>> the state of the systems.
>>
>> This isn't the only place I've heard Salt described as more of an
>imperative system (i.e. "Do this"), as opposed to a system that
>describes a desired state (i.e. "Make it like this"), which CFEngine
>does so well.
>>
>> However, having started to look at Salt, I don't really get the
>criticism (if you take it as one). Based on limited exposure so far, it
>seems just as capable as CFEngine or Puppet of specifying a desired
>configuration and executing on it; it doesn't seem all that different
>in overall philosophy. For anyone familiar with the issue, what am I
>missing? Or, perhaps, is that description of Salt based on earlier
>versions, the shortcomings of which have been addressed in current
>releases?
>>
>> - Leon
>>
>>> From: Atom Powers <atom.pow...@gmail.com>
>>> Date: November 13, 2014 at 12:45:26 PM PST
>>> To: "Edward Ned Harvey (lopser)" <lop...@nedharvey.com>
>>> Cc: LOPSA Technical Discussions <t...@lopsa.org>
>>> Subject: Re: [lopsa-tech] Puppet, Chef, Etc
>>>
>>> On Wed, Nov 12, 2014 at 4:42 PM, Edward Ned Harvey (lopser)
>>> <lop...@nedharvey.com> wrote:
>>>> I'd like to build a VM on my local vmware or virtualbox or
>whatever, and then essentially clone it to AWS or vice versa... Make
>some change on a development machine, test it, and then after it's
>validated, replicate that change to the production environment by
>sending essentia
>>>> lly the snapshot differential of the configuration.
>>>>
>>>> For some reason, this is what I thought puppet/chef/etc did. Am I
>wrong? Is this a pipe dream?
>>>
>>>
>>> This sounds more like Docker than Configuration Management.
>>>
>>> I've used CfEngine 2 for many years and Puppet for several. I know
>>> people who use Chef, Ansible, and Salt. Here are my impressions:
>>>
>>> TL;DR: it depends
>>> I would use Puppet when I have a wide variety of configurations and
>>> systems tend to stay in use for months or years.
>>> I would use Chef when I build a lot of similar systems and keep them
>>> up for days or weeks.
>>> I would use Ansible when I need to push changes to a system "right
>>> now" but don't need to manage the state of that system.
>>> I would use Salt when I need to build full application stacks
>>> including many dependent types of systems, and don't need to manage
>>> the state of the systems.
>>>
>>> Puppet is good for maintaining the state of your systems.
>>> It is, more than any other tool, it is a description of how the
>system
>>> should be configured.
>>> It is difficult to scale up to large scale (thousands of systems),
>>> mostly because all the work of building the catalog is centralized
>on
>>> the PuppetMaster.
>>> Because the PuppetMaster knows everything about all your systems it
>is
>>> trivial to do things like "create a Nagios check for all systems
>with
>>> Apache installed."
>>> Only the puppet master knows the secrets of all the systems, each
>>> system doesn't know anything about other systems; that makes it
>>> difficult to do something like "build the application server as soon
>>> as the databases server is built"; aka "orchestration"
>>> Puppet implements a DSL, so it is "easy" to rebuild it in other
>>> languages if the need presents itself.
>>>
>>> Chef is good for deploying systems.
>>> Chef is essentially an extension of Ruby, using Ruby syntax and
>>> libraries to create "executable documentation" about the system. You
>>> will *always* need Ruby on every Chef-managed system.
>>> Chef scales because all the work is done on the client, so the work
>is
>>> distributed.
>>> It can be easy to "accidentally" bleed secrets between systems
>>> because, typically (although I believe there has been work to
>correct
>>> this) each system gets the full set of instructions for every
>system.
>>>
>>> Ansible is, literally, "ssh in a for loop"; sometimes that is what
>you
>>> want. Ansible is great at deploying systems and at making instant
>>> changes to a group of systems.
>>> Ansible sends commands to each managed system or group or systems,
>>> runs the commands, and returns the output of the commands.
>>> You run Ansible manually, I haven't talked to anybody who runs
>Ansible
>>> on an automatic schedule like Puppet and Chef are typically used.
>>> I know people who use Puppet and Ansible together.
>>>
>>> I understand Salt uses a message queue to deliver configuration to
>>> systems, similar to how Ansible uses SSH.
>>> Salt is able to orchestrate configurations. It knows as soon as the
>>> database server is built and can start building the application
>>> server.
>>>
>>> I have a lot of love for CfEngine3, although I've never used it and
>>> don't know anybody who is.
>>>
>>>
>>>
>>> --
>>> Perfection is just a word I use occasionally with mustard.
>>> --Atom Powers--
>>> _______________________________________________
>>> Tech mailing list
>>> Tech@lists.lopsa.org
>>> https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
>>> This list provided by the League of Professional System
>Administrators
>>> http://lopsa.org/
>> _______________________________________________
>> Tech mailing list
>> Tech@lists.lopsa.org
>> https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
>> This list provided by the League of Professional System
>Administrators
>> http://lopsa.org/
>
>
>
>--
>Perfection is just a word I use occasionally with mustard.
>--Atom Powers--
>_______________________________________________
>Tech mailing list
>Tech@lists.lopsa.org
>https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
>This list provided by the League of Professional System Administrators
> http://lopsa.org/
--
Bryce T. Pier
_______________________________________________
Tech mailing list
Tech@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
