Idea for making Directory more powerful


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

source "etc_apt_sources_dir"
recursive true # should this be the default if source is specified?

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

But we can do better.

  1. 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”?

remote_file “/etc/foo/custom.txt” do
source "custom.txt"

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.

  1. 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.)

(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.)