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.
- 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.
- 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.
- 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=-