On Tue, Mar 22, 2011 at 7:20 AM, jcbollinger <[email protected]> wrote:
>
>
> 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.
That's a really good point. One workaround would be to encapsulate
such configs into a class and require that.
class foo::service {
service { "my_service": require => Class["foo::config"] }
}
class foo::config { ... }
Another would be to flip this around and instead use before instead of
require, so the service resource wouldn't need to know what kind of
object is required.
>
> 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?
Because of the clash between defining a symlink and specifying the
content of a file.
We have edge cases like this:
file { "/tmp/someobject":
ensure => present,
content => "foo",
}
Now if /tmp/someobject is a symlink (or even a directory), we need to
special case the code so that we log that the content attribute isn't
being used.
If it's a file, it will be used.
It gets worse with the "links" parameter.
file { "/tmp/foo":
ensure => present,
links => follow,
recurse => true,
source => "....",
}
This does all sorts of weird things depending upon whether the object
is a symlink, directory or file.
We've had requests to support sockets in the file type too, which
complicate things further.
>
> 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?
We have fundamentally different kinds of parameters on a recursive
file source than we do on a normal directory.
Think about the clash between source and content. links. purge.
recurse. recurselimit. ignore.
All those things *only* make sense with a recursive tree, not with a
single file or a single directory.
>
>
> 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.
like our existing "target" property? How does it make sense to manage
a symlink in a Directory type? I'm not seeing it....
> 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.
I think you're overlooking the configurable properties for recursive
copies. A function isn't going to give you all the options that are
widely used now.
--
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.
