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 <[email protected]> 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 [email protected]. > 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 [email protected] -- 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 [email protected]. 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.
