The Chef-branded distribution is still built from the same open source repositories that the CINC project is built from; it isn't proprietary. It has an additional EULA that requires people to accept and thus [presumably] pay for.
It's basically the same model as Red Hat. Except Chef never had the market penetration and brand recognition as a trusted source that Red Hat has.
Signed, someone who worked for Chef for almost 13 years.
With Chef 11 Server, the CouchDB component is removed for PostgreSQL. RabbitMQ is still there. Opscode provides a single package with everything above libc required to run the server.
When you run this on a system, like a throwaway VM or EC2 instance, it will download the cookbooks required for this run list, which you can review what they're going to do after the synchronization step of Chef is complete. With rayburst, the cookbooks will be synchronized into /var/cache/rayburst.
My point is that Rails does not take the high road of providing better, sane, secure defaults for people to build their applications.
While the proposed solutions in the issues I linked to were denied, it doesn't mean there shouldn't be some solution added to Rails. This is definitely a case of convenience favored over security.
1. Yeah, the stop-gap "solution" is to white list a number of attributes in order to reduce the data set, because in the most common use case we see, there's only a few attributes that people actually care about in the chef-client context. The node's run list, its IP address or FQDN. Really. That is the most common. For like, 90%+ of the use cases out there. Everyone has a unique snowflake and thats cool, but really, not that much.
2. There's no assumption that systems are correctly configured other than they start from a baseline configuration in the most common use case. We have worked with several customers managing existing infrastructures of running systems that had an unknown baseline and Chef was able to automated the pieces they cared about.
1. We are working on making the search more performance and use less memory.
2. Chef definitely does not discourage declarative configuration. Chef recipes include declarative resource for configuring your infrastructure. Since recipes are an internal ruby dsl, there may be nondeclarative code in them.
3. Chef itself doesn't have a remote trigger mechanism because the. Her run is all about configuring the local node. Nothing prevents you from using the ruby language in a recipe to hook up some kind of remote trigger though. People in the chef community are doing this with projects like Noah and Pylon.
To be clear, those dependencies are required for running your own open source chef server.
You can use chef without the server, as chef-solo, or let Opscode run it for you in the form of Opscode Hosted Chef. We do make it easy to install Chef Server through Chef Solo itself, or with our Ubuntu/Debian apt repository.
Actually in an upcoming release of Chef, you'll be able to do exactly that - manage Rackspace cloud nodes with the knife command-line tool. What that means is, you can launch new RS Cloud servers with knife, passing in the validation certificate and a run_list of recipes.
For EC2, Opscode provides a reference AMI with Chef pre-installed on Ubuntu 9.10 with a special configuration file that can parse EC2 metadata through Ohai to automatically validate and run a set of recipes. See:
One of Chef's benefits for managing a dynamic environments is the Search Index feature, which can be used to search for other nodes that have particular roles or attributes set. That is part of what the application cookbook does to dynamically deploy and connect with other systems running services like memcached or mysql.
As for the learning curve and getting up to speed, that varies by person.
It's basically the same model as Red Hat. Except Chef never had the market penetration and brand recognition as a trusted source that Red Hat has.
Signed, someone who worked for Chef for almost 13 years.