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 <john.bollin...@stjude.org>
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 puppet-dev+unsubscr...@googlegroups.com.
> 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
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%2BFoVCsd7iZU2z4ie3EfwSwqybg-9Tt0zbNjiA0DY0Aq39iw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
