On Tuesday, April 12, 2011 at 7:12 AM, Ringo De Smet wrote:
Hello all,
Initiated by the work I wanted to do for Vagrant ticket 248, titled
"Add Chef provisioning using 'knife bootstrap'" [1], I came to a
proposal that includes some changes to 'knife bootstrap'.
Let me first explain a bit what that Vagrant ticket is all about. At
the time of writing, a Vagrant base box already needs Chef installed
on the base VM if you want to use the Chef provisioner. My aim with
this ticket is to remove this pre-requisite. I want to prevent
rebuilding base boxes when a new Chef comes out. However,
implementation wise, I want to prevent any form of duplication on
installing Chef with what Chef already provides. The Opscode team
already did a great job on 'knife bootstrap' and this is the direction
my proposal goes. Here we go...
First of all, I would like to get rid of the limitation that 'knife
bootstrap' can only install a Chef client that works against a
functioning Chef server. My idea is that 'knife bootstrap' is split in
the Chef installation part and an optional Chef run part. The first
section just installs Chef via the distribution/template support.
After the installation, the bootstrap can optionally execute a first
Chef run. Why optional? Well, looking back at the Vagrant ticket, I
just needed a Chef client installed (when it wasn't available on the
VM yet) and I would like to use this updated bootstrap functionality
for that. Once Chef is installed, the Vagrant provisioners will take
over and I don't need the first run from 'knife bootstrap'.
For someone not using Vagrant, but using the knife command line client
itself, splitting the installation part from the first run opens up
the bootstrap to a whole lot of new possibilities. The bootstrap
command accepts a run-list, any run-list. Why should this only be
limited to a Chef client running against a server? Yes, to have the
cookbooks and roles available. But what if we augment the
functionality such that a tarball can be downloaded with the
cookbooks/roles needed for a chef-solo run? AFAIK this eventually
covers both chef-client and chef-solo runs for 'knife bootstrap'.
With knife bootstrap eventually supporting any type of Chef run with
any run-list, it would be possible to also bootstrap a server this
way. However, this depends on COOK-461 [3] and CHEF-2044 [4] to be
implemented if one wants this for Chef 0.10.0.
As a side note, for a generic chef-solo run, it would be very handy to
have a cookbook download including dependencies. As an example, if I
want to deploy a Chef server on the first run, downloading the chef
cookbook including deps would make it very easy to get everything
installed!
While I'm at it, it would be a good time to add support for specifying
the version of Chef to install, as requested in ticket CHEF-2195 [2].
The distribution/template files just need a slight update for a rename
of the variable. Instead of using config[:prerelease], I would go with
config[:version]. This config variable could get the string "--version
0.9.14" or "--prerelease". All cases covered!
gem install ohai chef --no-rdoc --no-ri --verbose <%=
" :version]}" if @config[:version] %>
I consider this proposal a bit of cleanup to minimize any real
bootstrap, so that Chef can take over much faster and in/for more
cases. If this idea/proposal gets traction, a complete and more
detailed proposal will be submitted to this list with an update of the
command line arguments to the knife bootstrap command and some example
command lines to explain...
[1] https://github.com/mitchellh/vagrant/issues/248
[2] http://tickets.opscode.com/browse/CHEF-2195
[3] http://tickets.opscode.com/browse/COOK-461
[4] http://tickets.opscode.com/browse/CHEF-2044
Awaiting some nice feedback! :-)
Ringo
Archive powered by MHonArc 2.6.16.