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.
For more options, visit https://groups.google.com/d/optout.
