Ok, you certainly have a working counter example, but I feel that it *should* actually fail and that this is a bug.
The expected state of the system is: 1) Make a FIFO file at /other/path 2) Set permissions on /other/path 3) Link /path/link to /other/path 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. A dangling symlink is a bad thing in every scenario that I can think which is probably why they're bright red in most shell syntax highlighting. So, I still think that the autorequires on the target, in the case of a symlink, is the correct thing to do from both an expectation and semantic point of view. Thinking about this further, should Puppet even be able to create invalid symlinks? 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. Thanks, Trevor On Fri, Feb 27, 2015 at 3:30 PM, John Bollinger <[email protected]> wrote: > > > On Thursday, February 26, 2015 at 2:28:22 PM UTC-6, David Schmitt wrote: >> >> On 2015-02-26 20:31, John Bollinger wrote: >> > > >> > Symbolic links do _not_ have the same kind of relationship with their >> > targets. A link can be managed entirely independently of its target, >> > therefore Puppet should not automatically demand a particular order. >> > As a general rule, it is important for resource types to model their >> > corresponding physical resources as cleanly as possible, lest >> > unintended consequences arise. In this particular case, autorequiring >> > link targets can create dependency cycles in cases that would >> > otherwise be perfectly good. >> >> Examples please? Everything I can currently think of right now (and >> it's night time here, so please be gentle) would create invalid >> filesystem layouts if the symlink points to one of it's own >> subdirectories. > > > > I don't think File autorequires would do it all by themselves, but they > don't exist in a vacuum. Any time you establish a constraint on the model > space that does not reflect a genuine constraint on the target space, you > make a portion of the target space impossible to model. "Constraint" and > "impossible" are a bit too strong here, of course, because you can override > autorequires, but any circumstance in which you need to do so highlights a > flawed autorequirement. > > Here's a contrived example: > > file { '/path/link': > ensure => 'link, > target => '/other/path' > before => Exec['create-target-as-fifo'] > } > > exec { 'create-target-as-fifo': > before => File['/other/path'] > } > > file { '/other/path': > owner => 'fifo_own', > mode => '0600' > } > > > The script 'create-target-as-fifo' is imagined to read the symlink > dynamically to determine where a FIFO is supposed to live (i.e. the > symlink's target), and create that FIFO if it does not already exist. > Afterward, Puppet manages the ownership and mode of the FIFO via an > ordinary File resource. This requires the symlink to be managed before its > target, as is reflected in the declared relationships, and if Puppet adds a > requirement of the type proposed then it closes a cycle. > > I don't particularly expect that specific pattern to crop up in the wild, > but I *do* expect all sorts of other weird stuff to crop up, and it would > be unreasonable to assume that it will all be safe with respect to the > proposed autorequirement. If the use case served by the proposal were > bigger or harder to serve by mechanisms already available in Puppet, then > perhaps I would be more open to sacrificing correctness for convenience, > but such is not the case. > > > >> > I observe, too, that in the example presented, the convenience >> > afforded by the proposed autorequirement is a function of the *use* >> > of >> > the resource, not inherent in the resource itself. Puppet cannot know >> > that, or be expected to account for it. It is the manifest author who >> > should be expected to take responsibility for modeling such >> > site-specific requirements. >> >> I would argue, that the primary *use* of a symlink is to point to >> something. Even in the obscure case of pointing to something that is >> managed as ensure=>absent, I would posit that the intended state of the >> symlink is only reached after its target's managed state is reached too. >> >> > > To be sure, the intended state of the *system* is reached only after the > link target's managed state is reached, but the state of the symlink itself > does not depend on or incorporate the state of its target. My example > above serves as a plausible -- albeit unlikely -- counterexample. > > > 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/6b2d70cc-0293-4d66-8b32-08cd56ba130f%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/6b2d70cc-0293-4d66-8b32-08cd56ba130f%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%2BFoVCsd7iZU2z4ie3EfwSwqybg-9Tt0zbNjiA0DY0Aq39iw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
