Am 31.03.2011 16:56, schrieb jcbollinger:
3. Sockets, FIFOs, devices, whatnot
[...]
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..
Yes, of course.
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.
Yep.
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.
I was thinking about something like "foreach" in the DSL, so you could
simply write something like the following:
foreach($path in recursive_file_list(
'puppet:///path/in/my/module',
'/path/to/base/dir',
2)
) {
if $path[type] == 'File' {
/* explicit setting of parameters */
file { "$path[title]":
source => "$path[source]",
owner => "$path[owner]",
mode => 0664,
}
}
else if $path[type] == 'Directory' {
/* implicitly taking all parameters from $path */
directory { $path }
}
else if $path[type] == 'Device' {
/* combining both */
device { $path }
Device[$path[title]] {
requires => File["/sbin/MAKEDEV"]
}
}
}
where recursive_file_list($puppet_uri, $client_path, $recursion) yields
an array of hashes.
This allows for all kind of neat tricks as you can now generate
resources based on something that's returned from a function.
Additionally this can be done *before* we start to interpret any types
and resources defined as it is essentially doable by some kind of
preprocessor.
The Problem I see with your variant is that the resources are created by
your function. This unneccisarily constrains flexibility. My variant
allows you to do something like the following:
foreach(dir in only_dirs(recursive_file_list(...))) {
...
}
Using recursive_file_list() yields an array of hashes which only_dirs()
can then filter to only contain directories.
Or maybe a function force_mode() that takes the minimum permission bits
which is then simply ANDed with the bits read from the filesystem.
last but not least the "not harder to understand than what we do right
now"-example:
$tree = recursive_file_list(...)
foreach(dir in only_dirs($tree)) {
directory { $dir }
}
foreach(file in only_files($tree)) {
file { $file }
}
I know this still looks complicated and is the *one* thing that would be
simpler with the old variant where the File-type does everything:
foreach(file in recursive_file_list(...)) {
file { $file }
}
However, the upper one definitely wins once you start to customize
parameters depending on wether it is a file or a directory (i.e. setting
the mode to 0755 instead of 0644). The main advantage is that
everything still works just like you had put the whole resource-list
into your manifest.
I think with that approach you'll be able to write much simpler
functions that are focused on a specific job plus you don't need to know
how to generate resources from inside a function.
Pushing information down to a function that generates the resources, as
you suggest, will make people write a special function for every
use-case instead of expressing what they want in the DSL using existing
functions.
And by the way: it is much simpler to debug a side-effect-free function
than debugging one with side-effects.
If you return an array of hashes you can always just print it out. If
your function generates a set of resources you'll need debugging-code
inside the resource-generating function just to find out what resources
are generated.
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.
