Issue #86 has been updated by volcane volcane.
I'm dead against anything that is non deterministic, giving file this ability
means you make it on par with installing a package with yum/apt etc and getting
a ton of unknown dependencies. You'd pick up on weird things like the package
situation in dev ofcourse but what about file{} as suggested above?
file{"/some/very/deeply/nested/file": create_parents => true}
in most cases this is fine as described, you get the parent dirs made once in a
sane and predictable way.
should I add file{"/some/very": ensure => directory, owner => "another" }
though the file resource above would *not* fix it. ie. /some/very/deeply
directory would not get adjusted to match the new parent dir ownership - see
below.
We just do not have state anywhere to say a file as in the first block also
created all the parents at some point months ago and store that for all future
invocations to then also create these additional resources. Even creating
resources on the fly to fill those gaps wont work because presumably on the 2nd
run the logic that made all the parent resources will be skipped since hte
parents exist already and as described we will leave existing dirs alone, else
where do you draw the line between not editing / ? or between not editing
/var/cache but letting it edit /var/cache/foo? there's way too many edge cases.
This further breaks if you have something like class apache::install { } that
sets up the parent dir for all your vhosts and such using this feature, on
another machine perhaps you created one of the parent dirs in another class
already using file{}. The result would be that if you included apache::install
on different machines the result across different type of machine would not be
the same and would not be predictable.
If you used specifically specified resources for each of the parent dirs you'd
*know* you're causing a screwup cos it just wont compile thanks to the
duplicate resource checks rather than silently creating a false sense of
certainty that your machines are all behaving in the same manner because puppet
built them and puppet is declaring the full known state.
I can imagine many many cases where this behaviour would result in
unpredictable results either through the life of a machine, through the life of
other machines that's supposedly *just* like this one (by including all the
same classes) or through other machines that tries to reuse classes used on
this one. The predictable behavior of puppets core types - like file, etc and
unlike augeas for example - is what makes it a usable tool.
Any added features that downgrade core types like file{} to something that's
unpredictable should be very very carefully considered.
----------------------------------------
Feature #86: Directory creation fails if parent directory does not exist
http://projects.reductivelabs.com/issues/86
Author: Redmine Admin
Status: Accepted
Priority: Normal
Assigned to:
Category: file
Target version: unplanned
Complexity: Medium
Patch: None
Affected version: 0.24.7
Keywords: feature
I tried
file {"/usr/local/share/puppet/sopext/facter" :
ensure => directory,
recurse => true
}
but get erros that the parent diretories are not available.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://reductivelabs.com/redmine/my/account
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" 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-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---
