Hmm....Ok, how about this: 1) Dangling symlinks are allowed 2) Warnings on dangling symlinks are the default (because you *probably* don't want them) 3) Setting :force => true, disables the warning message (in theory, you would only do this after seeing the message) 3a) For a less destructive method, something like 'dangle => true' could be allowed I suppose 4) Autorequires happen so that you don't get spurious warning messages
Would that work? Thanks, Trevor On Mon, Mar 2, 2015 at 10:10 AM, John Bollinger <john.bollin...@stjude.org> wrote: > > > On Friday, February 27, 2015 at 2:51:03 PM UTC-6, Trevor Vaughan wrote: >> >> Ok, you certainly have a working counter example, but I feel that it >> *should* actually fail and that this is a bug. >> >> > > [...] > > > >> I would like to propose that symlinks should naturally (i.e. >> autorequire*) come *after* all components of relevant file resources >> because otherwise they are systemically invalid. >> > > > I have just demonstrated that dangling symlinks are NOT systematically > invalid. They have inherent significance, however limited. > > In any event, don't lose sight of the fact that resource relationships are > strictly about *order of application*, not about semantic associations > between resources. The validity of a symlink in light of other elements of > the state of the system is a resource-relationship concern only to the > extent that it affects whether the symlink or other resources can be > applied. Whether a dangling link is acceptable or wanted is an entirely > separate issue. > > It is, moreover, a good general idea to minimize the number of resource > relationships by avoiding unneeded ones. Although a relationship *is* > needed (to ensure a viable order of application) in the case described in > PUP-4036, that's unusual and case-specific. It should also be readily > visible to the manifest author, and easily fixable without changes to > Puppet. > > > >> Thinking about this further, should Puppet even be able to create invalid >> symlinks? >> > > > Of course it should be able to do. Puppet is my tool, not my nanny. If > the target system allows dangling symlinks then Puppet has no good reason > to go out of its way to make it difficult to create them. It doesn't know > and shouldn't be expected to guess whether it's intentional, acceptable, or > wrong for any particular link to dangle at any given time. > > I'd be ok with warnings about dangling links, though, which potentially > Puppet could emit even when the link is already in sync. > > > >> I don't feel like it should as they can cause all sorts of havoc on a >> system with a code (expectation)-based infrastructure. Additionally, having >> Puppet complain on making a link to something that hasn't yet been mounted >> could be a very good thing since you would be aware that your underlying >> external system requirements have not been correctly met. >> >> It *should* leave invalid symlinks alone unless told to remove them, of >> course. >> >> > > Can we at least have consistency? If Puppet accepts dangling symlinks as > a valid, in-sync target state for existing resources, then it should not > refuse to manage resources into such a state. On the other hand, if Puppet > is unwilling to manage a symlink into a dangling state, then it should not > accept an existing dangling symlink as being in sync. > > > John > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/5e3447ea-8ebe-4cfa-85df-56decb5506d4%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/5e3447ea-8ebe-4cfa-85df-56decb5506d4%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUuTqXmpXbCDUzEEQ-uJ0HVvXDq9wq5ew-XMpuoUgiZ6w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
