On Mar 30, 11:05 am, Andreas Rogge <a.ro...@solvention.de> wrote:
> Having said that, it should be possible to do the following:
>
> Directory { "/u":
> ensure => link, (or maybe just ensure => present)
> target => "/home",
> ...
>
> }
>
> To ensure a symlink /u that points to a directory /home. As we now know
> this should be a directory the provider can fail if $target is not a
> directory and we can also generate a dependency on Directory["/home"].
>
> This would split out directory handling, allow for symlinks to
> directories and would even make the symlinking more deterministic,
> because you can check wether the target really is a directory.
Yes, indeed.
> 2. Files
> I'd suggest not to extend the possibilities of file any more. It should
> be able to ensure wether a file should be present or not and what
> content should be inside.
> As for directories the provider should check the target for the link
> really *is* a plain file.
Right on.
> 3. Sockets, FIFOs, devices, whatnot
> When handling stuff like this you should usually know what exactly
> you're doing and you mean what you say (i.e. if you create a socket you
> need a socket and not a fifo, dev or plain file).
> Thus every new filetype could be done as a new resource (hopefully
> sharing a lot of code with files and directories) with its own specific
> parameters. E.g. a Device needs block/char, major and minor just like a
> file needs its content.
Indeed. And here, too, you might want to work in symlinks to these
objects, especially if symlinks managed by the regular file type (2
above) indeed require their target to be a regular file..
> 4. Recursive Tree Copy
> The recursive tree copy has always been a bit weird. Don't get me wrong,
> but in puppet you're usually explicit: To ensure the presence of a set
> of files you'd explicitly list each file in your manifest.
> Obviously "the right thing" for a recusive tree copy would be to do
> exactly that: explicitly list every file and directory in your manifest.
> If that could be done at compile-time all was well.
> What we need for that is:
> - function to list all files/directories/sockets/whatever inside a tree
> - a method to loop over that list and generate the corresponding set of
> resources
And that's similar to my "resource generator" idea, so +1 overall.
People seem to agree that recursive tree copying is a different sort
of beast from the file and directory management that the File type
otherwise does. More open to debate, however, is whether that feature
should be split out into its own *type*, distinct from whatever type
manages directories without recursion.
I think not. Either it should be implemented as some other kind of
thing (not resource type) as suggested here, or it should be a sub-
type of a Directory type (if resource sub-typing were introduced).
"Some other kind of thing" might leverage the existing Puppet
framework (i.e. functions, hashes, etc.) to a greater or lesser
extent, but it would be nice to avoid making the feature significantly
harder to describe in a manifest than it is now.
Idea: instead of functions producing hashes, new iterative statements
in Puppet DSL, etc., what about a function that *accepts* a hash as an
argument, where the keys match the recursion-related properties of the
current File type, and which introduces the appropriate resources into
the target node's catalog? For example:
recursive_tree({
root => "/path/to/base/dir",
source_root => "path/relative/to/modules/file/dir",
recurse_limit => 2,
owner => "some_user",
group => "some_group",
mode => "0644",
links => "manage",
ensure => present,
purge => false
})
Taking a hash as an argument would provide for syntax similar to the
that of the File type, would more or less provide keyword arguments,
would support omitting properties. In other words, it would yield
most of the syntax and usage advantages of doing recursive copying via
the File type.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
