On Monday, March 2, 2015 at 1:50:08 PM UTC-6, Trevor Vaughan wrote: > > Well, there's my concrete example of where dangling symlinks are used in > the wild.... > > Ok, back to autorequires. I'm still not convinced that it's beneficial to > not have it in place. >
I am unlikely to persuade you if I have not done so already, but here is a summary of the pros and cons as I see them: *Advantages to symlinks autorequiring their targets*: 1. In the event that a symlink and its target are both managed as File resources, AND some other resource under management requires the target to exist before it can be applied, AND this other resource declares a relationship on the symlink instead of on its target (possibly via an autorequire), BUT no relationship between link and target is explicitly declared, THEN Puppet will pick up the slack to ensure that the missing requirement does not prevent the catalog from being successfully applied the first time. 2. There is no (2). *Disadvantages to symlinks autorequiring their targets*: 1. Many unneeded resource relationships are generated. 2. Under some circumstances, Puppet will needlessly create relationship cycles. 3. Although the autorequirement could be overridden, it would be impossible to model the usual true state of affairs, that the relative order of applying link and target *does not matter*. Note there that - the conditions for the autorequirement even having the *possibility* of a useful effect are pretty specific; and - even when the conditions are met, it's by no means certain that the catalog fails without the autorequirement; and - if the catalog *does* fail on account of the link's target not being managed soon enough, then it will be applied successfully the next time (barring other errors); and - any failure arising from a missing target -> link relationship will be easy to characterize and to fix; yet - dependency cycles are notoriously hard to understand and troubleshoot, especially when they involve automatic relationships; and - (this one's for you, Trevor) to fix a dependency cycle closed via an autorequirement such as we are discussing would require explicitly and artificially declaring the target to depend on the link, a relationship some find counterintuitive. > I suppose that I could do some hack-fu like I did with 'group' so that > people that want it could patch it into place but that seems a bit > unfortunate. > What's so bad about manually declaring a link to depend on its target when that's actually needed? If the situation in PUP-4036 is representative of such situations, then I don't see why a manifest author should even be taken by surprise by such a need. > > Are auto* items things that should be allowed to be disabled on a > resource-by-resource basis using a Metaparameter? That way you can do the > 'usual' thing but, should it cause an issue, just turn it off for that > resource and declare things explicitly. > > I don't see why it should be inappropriate for a parameter to modulate which autorequirements are in effect. Alternatively, if you want to cast link validity as an aspect of the File resource state then a new 'ensure' value could be created to model that. Perhaps something like "link-valid". When that 'should' value was in effect, the resource could reasonably autorequire its target, and would be expected to fail if the target did not exist when the link was being applied. > I'd much rather be able to shim in my own auto* items from the DSL (I > mean, it's an Array), > I don't follow you there. Do you mean you want some kind of global flag to enable the proposed autorequirements being generated? I don't see how that fits directly into the DSL, but you could address it within your own code by using a wrapper definition around the File type. Or if you mean on a case-by-case basis then what does "auto" have to do with it? Just declare the relationship you want. 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/b26f9b97-c98d-4ed5-b0c7-a09b9e8079fa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
