Issue #86 has been updated by Peter Meier.
> A stipulation can be made that when a directory tree is made, the "tree" only > can have one set of permissions/owner/group - as specified in the resource. > This would start with the directory that is missing, down to the leaf. - and this is exactly where this resource becomes unpredictable if on one host /foo/bar/a exists but on one one host only /foo/bar and your tree should create /foo/bar/a/b/c one one host puppet would manage (owner, etc.) folder a on the other not, where it might be different and for example not chmod 0755 which would break access to your leave for the daemon, which would make the puppet-run incomplete and not able to set everything correctly. Or: what if you have 2 trees: /foo/bar/a/b/c and /foo/bar/a/e/f in one tree the owner is set to root in the other it is set to mail. On a vanilla host /foo doesn't exist. So what is owner /foo? Maybe root maybe mail? depends on which host which tree resource would have been applied earlier. Furthermore in the second run: how would puppet know from which part of the tree it manages that resource and what should it do if somebody changes in the above example permission of b ? In the first run it would set them correctly and then somebody changes it and what would it do then in the second run? > ie - if /opt/local was there, and the resource called for creation of > /opt/local/lib/mylib/mysubdir the permissions/owner/group will start with the > newly created directories, starting with "lib", and including "mylib" & > "mysubdir". > > Absent could just be a dangerous "rm -rf" at the leaf level specified. ie - > using the above example if one wants to get rid of mylib/mysubdir, one would > say > > path => "/opt/local/lib/mylib", > ensure => absent, > recurse => true, and this makes it somehow very inconsistent: you wouldn't have the same state as if you first manage the tree and then set it to absent, you would have some parts of the tree left, which means that creating and removing a resource wouldn't do the same. > As said above, any complex permissions/owner/group should be handled > separately. > > If people want the file resource to chown, chmod or chgrp with a "-R/r", that > could also be done, but as a separate bug/feature. (I would say something > similar to absent... start at the point specified in "path" or "name") this can imho get very cumbersome. furthermore as puppet has the paradigma to manage a resource only once in a manifest you wouldn't be able to set the flags with a second file resource. > [...] > Sounds like this is a feature that a lot of people want. Yes, I agree on that. On the other side I can say that within the > 100 modules I wrote I encountered that problem maybe 10 times and half of them I realized that I create anyway a common structure for my systems which I can easily facter out into a seperate module and include that everywhere. And due to the auto-require of paths and the possibility to pass an array to the file resource the overhead is minimal. I know that minimal is somehow ugly, but: > Just need to agree on what the feature does :) and how it fits into the model that puppet tries to ensure and so far nobody came up with a solution that is consistent and is easy to use. ---------------------------------------- Feature #86: Directory creation fails if parent directory does not exist http://projects.puppetlabs.com/issues/86 Author: Redmine Admin Status: Accepted Priority: Normal Assigned to: Category: file Target version: unplanned Patch: None Affected version: 0.24.7 Keywords: feature Branch: 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://projects.puppetlabs.com/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.
