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.rb
recipe 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
Thanks for the comments! One point: knife and chef-client actually use the exact same Chef::Config class, whether or not that's a good idea :) There won't be any strict mode issues; there are just options that work in one and have no effect in the other.
I don't care if chef-solo really goes away; I just want a functional alternative. If people passionately want to save it in its current form I will live; we can have a debate on the merits of maintaining that code (and the alternative codepaths it creates). It's certainly not key to the main thrust of the proposal.