It takes a while to first learn Chef, even with http://learnchef.com. I'd like to get that time down. One of the big hurdles a new user encounters is the need for a server to do many important tasks. A second hurdle is a large amount of configuration and privileges the user needs.
I'd like to get learning Chef down to a 3-step, less than one minute experience of joy and success. And I don't want to do it by building special tools you only use when you're starting up; you should only be doing things that will stand you in good stead as you get more advanced.
Here's the 3-step of my dreams:
- Install chef omnibus (known 1-step install)
- Create a
cookbooks/startmeup/recipes/default.rbrecipe with a resource or two in it. chef-client startmeup
No setup besides the install. No configuration, no authentication, no server, no privileges. Pure recipes, up and running and getting value in no time.
This requires two things: first, we need a server (and I nominate chef-zero). We integrate chef-zero tightly (and invisibly!) with chef-client and knife. Yes, you need a server, and we'll GIVE you a server that you don't even know about. Second, we need users to be able to run chef-client by default WITHOUT root, which means changing some default configuration like repositories and caches to point to accessible places.
The command, again:
chef-client startmeup
- Don't require a server
The first thing we need is the option to start up a local chef-zero instance, pointed at the user's local repository. In this proposal, the chef_zero.enabled option will accomplish this. chef_zero.port allows you to decide what port (which defaults to 8889). When the chef-zero server is started, chef_server_url will be set, meaning all knife and chef-zero operations will proceed as normal. This should come with a command line option as well so that one can quickly switch between one's server and local mode.
A further enhancement would be to allow a range of ports to be specified, so that if one is taken, we will try to start up on the next one.
To avoid configuration, chef-zero needs to be the default when running in a local repository like the above, when no configuration file is specified.
Keys must not be required for Chef::REST (or invisibly supplied). When not supplied, requests will not be signed (and we let real servers return the requisite 401).
- Let normal users run chef-client by default
When users run Chef, by default it points to cookbooks and such in /var/chef/cookbooks. This needs to change. If no configuration file is found, Chef should first detect if it is running in a repository (by looking for a cookbooks/ dir just underneath or above it in the path) and set the chef_repo_path to that.
Even with the location of cookbooks and other data fixed, Chef still has some operations that touch caches in /var/chef/cache and the like. If no configuration file is found, Chef should set the cache to /.cache.
- Make the command line accessible
When running chef-client locally, it is convenient and intuitive to just type recipes out on the command line. We should allow non-named arguments, and treat them as an overriding run list.
It may also be useful to allow users to type filenames, so that tab completion comes into play, a la knife-essentials:
chef-client cookbooks/apache2
chef-client cookbooks/apache2/recipes/server.rb
cookbooks$ chef-client apache2
On the other hand, I think it becomes obsolete because it becomes redundant, not because solo was a bad idea. It becomes obsolete because it provides a strict subset of the functionality you could have with Chef.
Running local cookbooks, without a server, is a great idea. Having an invisible server is just a means to that end in my humble opinion, and I won't have any issue at all if someone finds a way to implement all the functionality without involving an actual server! I think there are definitely ways.