Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Salt: Like Puppet, Except It Doesn’t Suck

blog.smartbear.com

Post reply on HN
Print view View original

161–170 of 274 posts

Re: Salt: Like Puppet, Except It Doesn’t Suck

#161

Post by dsl »

emidln wrote: post #114
tptacek wrote: post #52

Earlier quoted context omitted.

Awesome. How many people have reviewed it for flaws? How many people have reviewed OpenSSH?

How many people have reviewed Paramiko? In particular, how about that ecdsa patch[1] to Paramiko that you'll need to be accessing modern Ubuntu or Fedora (and before long, RHEL/CentOS). What about the python-ecdsa[2] (that paramiko's provisional support for modern Fedora and Ubuntu's default configs is based on)? This entry from its README seems pretty frightening: This library does not protect against timing attacks…

> Do not use it on a system where os.urandom() is weak.

So, don't use it in the cloud? [1]

1. http://harvey.binghamton.edu/~ychen/chen-kerrigan.pdf

Re: Salt: Like Puppet, Except It Doesn’t Suck

#162

Post by sabat »

susi22 wrote: post #26
cultureulterior wrote: post #19

Personally, I don't think puppet sucks

The problem is most dev-ops and sysadmins don't know ruby and that's a HUGE disadvantage. In the end configuration management will often by done by sysadmins.

most dev-ops and sysadmins don't know ruby

I beg to differ—if you call yourself a devops person and you don't know Ruby, you're somewhat rare. Yes, yes, python, blah blah. But most of us do Ruby, partly because that's what the most popular, widely used tools are written in (Chef, Puppet), and partly because it's an elegent and easy-to-understand language.

If you say you're devops and you don't do anything besides Bash: you're not devops.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#163

Post by rektide »

justincormack wrote: post #82

I much prefer the immutable server model [1] to the puppet model. Build a new tested server with the new config and roll that out. [1] http://martinfowler.com/bliki/ImmutableServer.html

There's words written about "automatic configuration" in that link but I don't see any guidance or information on what those configuration tools are. The focus is certainly not on automatic configuration: the focus is on use and re-use of images, on taking images, doing something to them, and getting new images.

The notion is deeply flawed to me: using an image as a precondition for making an image, over time, becomes an intractable mess and requires very careful supporting documentation to prevent the scheme from devolving into a bunch of "buckets of bits" with no transparency into what work has gone on to make it that way.

The #1 thing that I enjoy about automated tooling is that I can take a bare OS and spin up a complete new system in a matter of minutes, and I get to watch that entire process happen before my eyes. There's no mystery, no external dependencies, no existing work I'm riding off of: everything that happens is visible to me in an immediate way.

There's a value & use to immutable images, but please decouple your image making from past images made: no one wants to root around to figure out what twelve horrible things you did to install Java 9 image instances back whenever, nor are they going to have any fun reproducing it on the twenty nine active variants of that ancestor image when there's a security fix to be done.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#164

Post by mechanical_fish »

contingencies wrote: post #133
mechanical_fish wrote: post #125

Earlier quoted context omitted.

a cleaner solution is to deploy configuration changes from scratch, by deploying clean-slate instances with those changes made. All of us who have built big cloud-server clusters have dreamed of this plan at least once. But there are big practical problems. Relaunching infrastructure is easy in theory, but from time to time it becomes very difficult. There is nothing like being blocked on a critical upgrade because y…

The bulk of your comment - your second, third and fourth paragraphs - focus on issues of speed, bandwidth and reliability in a third party hosting/cloud-based architecture, which are a design-time tradeoff, so I don't see them as strictly relevant (though anecdotally informative). Your fifth paragraph describes problems related to operations process, which are entirely avoidable.

Well, okay. Give my regards to Saint Peter and all the angels!

Re: Salt: Like Puppet, Except It Doesn’t Suck

#165

Post by johtso »

nwmcsween wrote: post #121
danudey wrote: post #83

Earlier quoted context omitted.

These tools allow you to specify a state and then specify which servers should have that state. A 'state', loosely speaking, is a collection of definitions of 'X should be Y'. For example: Package 'libapache2-mod-php' should be installed. File '/etc/apache2/sites-available/customersite' should be the contents of this file we have on the master server. File '/etc/apache2/sites-enabled/customersite' should be a symlink…

But the problem that all of the configuration managers have and also why they all suck is that the state you specify has no guarantee of being the end state. A much better alternative would be to manage state in chunks and test those chunks, e.g an http-server transaction would require responding on port 80 if not fail or roll it back. Rolling back could be using namespaces, jails, etc.

You might be interested in Salt's requisite statements: http://docs.saltstack.com/ref/states/ordering.html#requisite...

In combination with service.running you can require that, for example, package x is installed, and its service is running, before service y is started.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#166

Post by showerst »

nwmcsween wrote: post #121
danudey wrote: post #83

Earlier quoted context omitted.

These tools allow you to specify a state and then specify which servers should have that state. A 'state', loosely speaking, is a collection of definitions of 'X should be Y'. For example: Package 'libapache2-mod-php' should be installed. File '/etc/apache2/sites-available/customersite' should be the contents of this file we have on the master server. File '/etc/apache2/sites-enabled/customersite' should be a symlink…

But the problem that all of the configuration managers have and also why they all suck is that the state you specify has no guarantee of being the end state. A much better alternative would be to manage state in chunks and test those chunks, e.g an http-server transaction would require responding on port 80 if not fail or roll it back. Rolling back could be using namespaces, jails, etc.

Ansible allows you to do this, it has failure modes that let you take actions, including rolling back.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#167

Post by AaronBBrown »

This article makes a claim (...Puppet...Suck(s)), but does not take even attempt to explain what it is that sucks.

What, specifically, "sucks" about Puppet and Chef and what is so much "simpler" about Salt or Ansible? As an Ops guy who has been running Puppet since 2008 (and Chef most recently) against hundred of servers, I don't see the simplicity reflected in the documentation, nor do I find Puppet or Chef particularly complicated.

(Ok, Chef's attributes system is a bit confusing at first, but it is hugely powerful.)

Re: Salt: Like Puppet, Except It Doesn’t Suck

#168

Post by druiid »

apenney wrote: post #147
druiid wrote: post #106

Earlier quoted context omitted.

Well, rabbitmq is kind of a pain to get working with it. Additionally, the modules for rabbitmq and mcollective, for puppet, don't really work that well together (read: I had to re-write the ones I found to get them working).

I'm starting work at Puppetlabs in exactly a week's time as part of a brand new "module team" and I personally promise you here and in the open that I am going to tackle the puppetlabs-rabbitmq module and fix it so that it actually works and isn't an abandoned wasteland. Come to that I'm hoping we can start building out a full set of mcollective modules to replace the existing ones that will be fully supported and ke…

FYI we've spoken in the #puppet channel about just this issue ;).

Re: Salt: Like Puppet, Except It Doesn’t Suck

#169

Post by fusiongyro »

AaronBBrown wrote: post #167

This article makes a claim (...Puppet...Suck(s)), but does not take even attempt to explain what it is that sucks. What, specifically, "sucks" about Puppet and Chef and what is so much "simpler" about Salt or Ansible? As an Ops guy who has been running Puppet since 2008 (and Chef most recently) against hundred of servers, I don't see the simplicity reflected in the documentation, nor do I find Puppet or Chef particul…

From the article:

> Chef works atop ssh, which – while the gold standard for cryptographically secure systems management – is computationally expensive to the point where most master servers fall over under the weight of 700-1500 clients. Salt’s approach was far simpler.

I think I'm with you (without the experience): I find "it works over ssh" a lot simpler than "we wrote a custom protocol on 0mq." Simplicity apparently has lots of interpretations. I couldn't care less if ssh performs well enough to support a trillion connections. In practice, you only need a handful, usually one.

Maybe Salt is fantastic. I'm not really in a position to judge. The article made it sound interesting to me, but I'm not sure attacking Chef/Puppet was really necessary, especially since it wasn't really expounded on.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#170

Post by [deleted] »

lobo_tuerto wrote: post #15
susi22 wrote: post #12

IMO, ansible is even better: https://github.com/ansible/ansible/ It doesn't require any deamon and does all its work over the good old unix fashion way: SSH. And it's python too.

From the article: "Chef works atop ssh, which – while the gold standard for cryptographically secure systems management – is computationally expensive to the point where most master servers fall over under the weight of 700-1500 clients. Salt’s approach was far simpler." Does that assertion about Chef somehow don't apply to Ansible? On the use case: "I have this command I want to run across 1,000 servers. I want the…

[deleted]
Post reply on HN