I love how the first result when you google "chef-solo" is a list of all the things that it won't do for you, all of which are stated in jargon that a beginner cannot understand.

It might be more direct to replace that page with a single sentence: "chef-solo: We're Not Interested And You Shouldn't Be Either."

Or, might we consider compiling a friendly list of the great things chef-solo could do for you? I was going to work on that, but now I'm tinkering with Ansible instead.

I don't know what's the opinion of other people, but for me chef-solo is not even a product on its own. If you use chef, but need to either bootstrap the server or prepare some system image - then going the way of stripped down / hacked chef is what you're looking for. And that's what chef-solo does.

But maybe it's more of a standalone tool for others?

I use chef-solo with Vagrant, I rarely use chef-server/client with Vagrant. My dev box rarely needs to separate out environments, for example.

You do not need to bootstrap Chef 11. You download a single omnibus package and run a single line to install it. All dependencies are already embedded into the package. Under the covers, it bootstraps itself, but from the end user's perspective, It Just Works.

Came here to say exactly this. chef-solo _is_ good, particularly combined with things like Vagrant and Berkshelf

That's mostly just sales talk. The reality is that chef-solo works just fine for a lot of use cases, and that set of use cases has significant overlap with the use cases for ansible.

If a tree falls in the forest, but that tree is not mentioned in the documentation – indeed, if the documentation says something like "there's this forest, we used to live there, it's dirty and primitive and stuff, now all the cool kids live in Manhattan"...

The point is, the beginners never find the tree. They get lost, kind of like I've gotten lost in this metaphor, and they go try something else.

I would agree (if I understand the metaphor within a metaphor, that is) that documentation and best practices are probably the biggest weakness in the Chef community. Once you add in tools like berkshelf or librarian-chef where the tool creators recommend totally different workflows from those recommended by Opscode, not to mention the wide variety of testing stories... it's a mess. I've heard from someone at Opscode that fixing that mess is one of their priorities, but until then, it's definitely a problem.

Where we really need to be is a place where configuration management is just another part of application repositories (there's a parallel here to db migrations), so that web applications are completely self-contained. That includes versioning, unit testing, etc. I haven't yet seen any of the configuration management tools come forward with a solid unified best practice solution for treating applications this way, but there are a lot of people working in that direction, which makes me very hopeful for the near future.

There is a project called "littlechef" which allow you to use part of the chef-server's features without chef-server.

https://github.com/tobami/littlechef

It doesn't seem to include node storage, so for example you'll need to include a mysql password because if it generates a random one, you won't be able to retrieve it.

(This may have changed since last time I tried it.)

I should point out that Ansible can store passwords on the filesystem here, using the 'password' lookup plugin. So while there is no database you can still easily access things exactly like this.

To be fair, I don't think Ansible has any of those, either.

We're also adding some neat things around authentication and access control in a forthcoming product release, if you do decide you want those kind of "serverey" things. See here: http://www.ansibleworks.com/ansibleworks-awx/

But yes, you don't need these, Ansible can exchange variables between hosts in memory without needing a database, etc.

Can I ask why you chose GPL for Ansible? This makes it more challenging to integrate or embed Ansible in many types of commercial or non-GPL projects.

Chef [1] and Puppet [2] both chose the Apache license. Salt did as well.

If you were worried about competitors offering hosted versions of Ansible, I could understand going AGPL, but not GPL3.

Thanks!

[1]: http://www.opscode.com/blog/2009/08/11/why-we-chose-the-apac... [2]: https://puppetlabs.com/apache/

I come from Red Hat and I like the GPL, because it ensures the software remains free. I view GPLv3 as largely a language improvement on GPLv2, which makes it easier to understand and define how it applies.

Ansible being GPLv3 doesn't affect folks much. Your library modules can be licensed in any way you like, and it's fine to shell out and call ansible-playbook. AWX also exists as a nice API layer if you need a web services interface that abstracts you from the license question, so folks looking to do commercial integrations can tap into the REST layer.

AGPL is more restrictive than GPL, in some ways, as you can't use things in a hosted service. We didn't want to be that restrictive.

While AGPL certainly is more restrictive (that is the whole point of the AGPL after all) -- it does of course not prevent the use in a hosted service, it just has a requirement that the end user still has access to the source code (while with GPL you could change large parts of the Free code, and never contribute that back to the users, if you so chose).

As long as there is a REST bridge/layer, any service shouldn't be considered a derived work -- only changes to "core" Ansible would be "covered" by the AGPL.

I'm sure you know this, but it is an important point (just like the GPL never dictates that you have to contribute changes upstream, just to "your" users (which of course might include upstream, and most people feel it is more constructive to give back in the more general sense...)).

I've seen some strange (imnho incorrect) interpretations of the AGPL, hence this comment.

Right! It would prevent people from being able to use it in hosted services that didn't share the source, and we wanted to make sure people could easily use it in those things without any problems.

Ansible is licensed as GPLv3. But it sounds like AnsibleWorks-awx is a commercial-only product? Are future 'pro' features going to only be released and maintained in commercial variants of AnsibleWorks or separate related projects? Would love more transparency about the relationship between open and closed-source products at AnsibleWorks.

I made a similar clarifying request on the Ansible user group forum a few weeks ago but my message was not approved. I believe that these are fair requests and deserve clarification.

We've posted quite a lot about this to the list in the past, I'm not sure what happened to your post.

Ansible is GPL, and we're totally going to keep it just the way it is, and continuing to make it more awesome. (The application is just invoking ansible-playbook).

Why is it commercial? A lot of the stuff we are building is mainly interesting to enterprises -- RBAC, reporting, things like that.

The core things everybody needs to use Ansible today, all the modules, are free software and we will continue to add loads more there. Ansible received over 50 new modules in the last 2 releases.

K cool. Thanks for clarifying. Keep up the good work. :-)

How is that a fair request? Ansible is a GPL3 Python codebase. If the community doesn't like where AnsibleWorks takes it, they'll fork it.

for that list of features, you either don't need it because of how Ansible works, or there's an inventory plugin for it.

FWIW, environments should be in the next release.

http://tickets.opscode.com/browse/CHEF-3356