Am 29.03.2011 18:02, schrieb Nigel Kersten:
On Tue, Mar 29, 2011 at 8:16 AM, Joe McDonagh
<joseph.e.mcdon...@gmail.com> wrote:
I'd really prefer if the name of this resource didn't change. I understand
there are problems but can't you just split the code and have different
behavior based on something like filetype =>?
We're not going to rush into this, and we'll try to maintain backwards
compatibility as much as possible.
I'm probably totally wrong and didn't follow the puppet development tree
for a while, but I guess we should do the following:
1. Directories
We could split out directory-management and that would totally make
sense, because you handle files and directories differently.
However, from the admin's POV a symlink to a directory is a directory.
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.
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.
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.
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
Maybe general approach would help here. As far as I understood it is now
possible to return nested hashes from functions. Thus one could easily
write a function that for a given tree returns a hash that looks like this:
{
"/path/to/topdir" => {
type => directory,
mode => 0755,
[...]
}
"/path/to/topdir/file" => {
type => file,
source => "puppet:///modules/xyz/topdir/file",
mode => 644,
[...]
}
}
That can then be fed into a magic loop to generate
Directory { "/path/to/topdir":
mode => 0755,
[...]
}
File { "/path/to/topdir/file":
source => "puppet:///modules/xyz/topdir/file",
mode => 0644,
}
What do you think?
Regards,
Andreas
--
Solvention Ltd. & Co. KG
Egermannstr. 6-8
53359 Rheinbach
Tel: +49 2226 158179-0
Fax: +49 2226 158179-9
http://www.solvention.de
mailto:i...@solvention.de
--
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.
