[chef] Idea for making Directory more powerful

[< >]

http://wiki.opscode.com/display/chef/Resources#Resources-Directory

The documentation for Directory says "it manages a directory", but really it
only creates/deletes directories and manages mode bits.  To really "manage" a
directory, you need to manage the files in it.

1) the directory resource could look in files/default/DIRNAME (like the
remote_file resource) and recursively copy the files over (kind of like 
rsync).
 Maybe you need to specify a source option, so it's back-compatible with
existing scripts.:

 directory "/etc/apt_sources" do
   # recursively copies files in files/default/etc_apt_sources_dir/* to
/etc/apt_sources/.
   source "etc_apt_sources_dir"
   recursive true # should this be the default if source is specified?
 end

This could probably be implemented quickly by creating (remote_)file resources
for each file.


But we can do better.

2) The Directory resource could _really_ manage a directory: Actively delete
anything that's not supposed to be there.

Currently, there's no way to do this. For example, imagine I have a dynamic
list of virtual sites that I want to translate into "/etc/httpd/sites.d" (one
file per site).  If I use remote_file resources, Chef will leave stale copies
of old sites everywhere. The current 'solution' is to go wild with definitions
(macros) and/or custom resources/providers. Yuck -- because now I can't copy
over a file with "(remote_)file" anymore.  In fact, I might have a different
custom macro to deal with every directory of files I want to manage.  Even
worse, I can't mix in an existing simple recipe for that directory any more --
I have to modify all existing recipes to use this new "macro".


What if Chef could *really* manage a directory?  It's simple: Just remember 
all
the files you put into that directory and actively delete any leftovers. It
would look like this:

 directory "/etc/foo" do
   source "boilerplate_etc_foo"  # assume first part is implemented
   recursive true
   manage true       # or should that be "mange :delete"?
 end

 remote_file "/etc/foo/custom.txt" do
   source "custom.txt"
 end

If I comment out the remote_file resource, it should delete the custom.txt
file. If I change the name of the file, chef should not let a stale copy lay
around. In theory, it wouldn't matter if the remote_file resource was before 
or
after the directory resource. That way, existing recipes wouldn't have to be
changed when you decide to turn on management of a directory in a new recipe.

If we're backing up ("mange :backup"?) instead of deleting stale files, we 
will
need a sane backup policy to prevent the "bad" files from being renamed over
and over on every run.

3) The next concept: Chef could manage multiple overlapping directories with
"cut-outs". You should be able to say "manage /etc, but don't manage
/etc/resolv.conf". (maybe use a blank file resource?)  Or you should be able 
to
have one recipe manage "/etc" and another recipe manage "/etc/dns", with the
"right" thing happening if you use any combination of recipes.

If you take this to it's logical conclusion, you get Radmind. (But unlike 
Chef,
Radmind is a one-trick pony.)
http://rsug.itd.umich.edu/software/radmind/

(Yes, I know I'm asking for the moon. Really, I'd be happy with just #2 above,
which doesn't even require #1 to be useful.)

-=Dan=-