On Mar 21, 8:53 pm, Nigel Kersten <[email protected]> wrote:
> The file{} type can do all of the following:
>
> * manage single files
> * manage directories
> * manage symlinks
> * manage recursive file copies
>
> The intersection of all these bits of functionality makes it difficult
> to understand exactly what is going on when you're new to Puppet, and
> even experienced users often don't know how combining symlinks/content
> management is going to work.
>
> How would people feel about at least splitting out these into their own types?
>
> * symlinks
> * recursive file copies
>
> The intersection of files and directories isn't that big a deal, but
> we could split out directories too if we wanted.
>
> Thoughts?
I agree that File is a mishmash, but I don't think symlinks and
recursive copying are the key concepts that would be good to split
out. Instead, I think splitting directories into their own type would
be the way to go.
Consider what would happen if symlinks were made their own type. What
about dependencies? Right now, I can have
service { "my_service": require => File["/etc/my_service.conf"] }
without caring whether File["/etc/my_service.conf"] represents an
actual file or a symlink. I can even change that in the declaration
of the file without having to touch anything that depends on it. If
symlinks were modeled via a separate type, however, then I would need
everywhere to account for which files were plain and which were
symlinks.
Or look at it from a modelling angle: a symlink to a regular file is
much more like a regular file than a directory is like a regular file,
so why does it make sense to split out symlinks but not directories?
Parallel arguments can be made about directories and symlinks to
directories.
As for recursive copying, that's an action, not an observable,
manageable artifact, so why would it make sense to create a resource
type around it? It could be recast as something like "directory
hierarchy", but that begs the question of why it should be separate
from ordinary directories. If you want to think out of the box, then
consider re-implementing recursive directory management via a new
(type of) function that dynamically adds all the appropriate Directory
and File resources to the catalog. That's anyway what Puppet already
does, right?
This, then, is the direction that makes the most sense to me:
1) Split out (only) directories into their own type. Among other
things, recursive-tree management would go into the new Directory
type.
2) Give File and Directory each a "link_to" property by which these
types can be made to manage symbolic links instead of the underlying
regular file or directory.
3) Once (1) and (2) are done, it will be possible and appropriate to
limit the allowed values of both types' "ensure" properties to
"absent" and "present".
I recommend seeing how (1) works out before trying to move recursive
directory management into its own entity. If that feature is indeed
moved out, however, then I truly don't see how it would make sense to
make a resource type out of it. Making a function out of it instead
would be a better fit.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
