[ryanpers]

NT = neurotypical, standard lingo in "aspy" forums. You're probably pretty normal. Expect eye contact and all.

On a technical note, it's not clear to me how you KNOW that chef or puppet has solved your system state problem. Now if its limited to doing super basic stuff, ok great, but then you really arent adding enough value to justify the huge cost of these systems.

I'd also like to hear what you have to say about "throw software on top of it"... for example, I want all 40 webservers to have the same build revision of our codebase. But I need positive feedback - and a gradual rollout possibly. Eventually run puppet clients really dont tell us this. Oh wait, I mean I want to rollback to the previous deployed version, because it's broken horribly.

These practical software deployment issues I find just are not addressed by the system configuration management tools like chef, puppet.

And that is why they are so passionate about it, because a million people have told them 'just use chef' and yet chef doesnt solve their problem at all, nor does it solve any fraction of their problem either.

[cparedes]

I can't know for sure, but it's at least corroborated with quite a bit of research: https://www.google.com/search?q=usenix+configuration+managem...

I'm a fan of both of those systems, because it's easier to express system state with them (and clearer, too), versus using shell scripts or what have you. I'm definitely not advocating using it as a way to deploy software, but it's definitely possible to do so (I'd likely build system packages, throw them in an internal repo, and use yum/apt to ensure software packages are up to date, or at a certain version.)

It's not the only solution, though. I've worked at shops where there have been exceptional software deployment pipelines that are absolutely not tied to a configuration management system. I'm also not a fan of using Chef or Puppet for doing a git/svn repository checkout of software.

Again, I want to reiterate my point: it's still not about the tools, but about identifying the problem you need to solve and discussing possible solutions to the problem. There's no right answer.

[ryanpers]

This is a pretty typical answer I've gotten from various people. First off, no one should ever (a) be using SVN EVER and (b) be checking out in production as a way to get code there.

So you said "use yum/apt to ensure software packages are up to date, or at a certain version."

So how do you make a 100 node cluster get to the desired installed state? Do it by hand? Ssh loop? cssh or similar tools that attempt to do parallel ssh? This is the part where things really break down and then I realize there actually is no principled way to do it, and in fact it's done by hand, and the sysadmins are just creating more work for themselves ensuring job security.

[cparedes]

Kick off Puppet/Chef runs? It's not too hard to automate these tasks, either (or even put a fancy interface around it, though of course this takes a bit more time.)

It's also a bit insulting when you say that we 'in fact [do it] by hand', because sysadmins, as a whole, strive to not do that. Fine, I can see myself logging into a box and typing 'chef-client' or 'puppet' by hand - but this is too much work to be done by hand. That's why we automate. I don't know why you have this idea that we simply want to make things harder just for job security.

[ryanpers]

I have run into sysadmins who prefer to be manual, and avoid automation.

I have a destination in mind, and I'm always looking for new travelers. But I havent seen many lately.

[troels]

Assuming the puppet configuration is kept in a (git) repository, can't you use that to manage the issues you mention there? The main repo lives on the puppet master, and has a post-receive-hook that ssh's in and updates clients. A rollback is done by updating the head to a previous version and pushing. Voila?

[ryanpers]

the issue is once you get to 100 nodes. you are issuing a 100 node ssh loop from a git-post-receive hook? I'm wary of that.

[cparedes]

You can replace 'ssh loop' with parallel SSH connections, or pubsub, or...