On Feb 15, 3:29 pm, Daniel Pittman <dan...@puppetlabs.com> wrote: > On Tue, Feb 14, 2012 at 06:54, jcbollinger <john.bollin...@stjude.org> wrote: > > [...] As I understand it, the issue is not > > with "putting a symlink in a module" but rather with recursively > > managing a directory tree that contains symlinks. Modules appear to > > have nothing to do with it -- it's all about the behavior of the File > > resource type. > > That is more or less true; modules are relatively unrelated to this, > although part of the motivation is understanding how to make things > more predictable so we have less headache getting reusable modules > built up.
Fair enough. As to the main issue, then, I recognize that the File resource's recursive directory management is a perpetual source of headaches, but I'm not seeing why its documented (but failing) behavior with respect to symlinks is inherently worse than the rest of the recursive management stuff. Nor do I see why recursive management of symlinks as symlinks presents a particular issue for reusable modules. Furthermore, if it makes sense (and it does) for the File resource to be able to manage individual symlinks via "ensure => link", possibly augmented by "force => true", then why would it not make sense to provide the same capabilities in a recursive situation? Indeed, it would present an internal consistency problem if Puppet were willing to manage symlinks only for individual File resources, and not recursively. > It shouldn't require recursive file copying for this to take effect, I > think, but the uncertainty is part of the motivation here. If the File resource behaved as documented then there would be no uncertainty. With "recurse => true, links => manage, force => true" the File resource would always manage a node's corresponding directory tree into an exact match to the master's. Where is the uncertainty in that? The uncertainty arises because of a *bug*. Removing the buggy feature would clear up the uncertainty, but so would fixing the bug. Ergo, uncertainty is not a valid argument for removing the feature. 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.
