On 2015-02-26 20:31, John Bollinger wrote:
On Wednesday, February 25, 2015 at 6:06:33 PM UTC-6, Trevor Vaughan
wrote:
I think I filed a bug about this a while back.
+1 for autorequiring targets
+1 from me too. Slightly conditional on the discussion below.
I'm inclined to disagree. Autorequiring should be reserved for cases
where the requirement is inherent in the resource's nature. Files'
dependencies on their parent directories are a good example (except
when ensuring 'absent'): when a file and its directory are both under
management, you cannot be confident of managing the file properly if
you do not first manage its directory.
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. Or, maybe a scenario where /srv/app is owned by
app_user, whose home directory is below /srv/app/something. But that
would be a cycle /srv/app -> owner -> home -> /srv/app without any
symlink.
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.
Regards, David
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 [1].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/1aecc279-4620-4a36-bfb4-8f38c9ea3479%40googlegroups.com
[2].
For more options, visit https://groups.google.com/d/optout [3].
Links:
------
[1] mailto:puppet-dev+unsubscr...@googlegroups.com
[2]
https://groups.google.com/d/msgid/puppet-dev/1aecc279-4620-4a36-bfb4-8f38c9ea3479%40googlegroups.com?utm_medium=email&utm_source=footer
[3] https://groups.google.com/d/optout
--
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/64316026360e35824b8c5dda368b57ed%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.
