Honestly, it seems like the majority is to not have this, so I'm happy to drop it if that's the consensus. I just keep running into the usual situation where I don't want dangling links.
For the other items: 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 > I agree, and I do understand that 'eventual consistency' is what is advertised. That said, I prefer one run to two as much as possible. > 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. > The main issue here is working around cross-module dependencies. I don't particularly want to create another module/class just for managing a symlink target that might be managed by multiple files. Also, it's just something else that needs to be explicitly declared when it seems to be the usual use case to me. In other words I think that, in most cases, I don't want dangling symlinks and I do want to make sure that the item that I'm targeting is present on the system already, regardless of its location in the module space. 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. > *This I like, very much!* I'd be happy with something like 'link-valid' being added to the File resource and autorequirements being spawned from that. I do feel, though, that this would be the generally expected use case. I.e. don't you always expect your links to be valid in general? So, can I vote for adding '*validate_link => :boolean*' as a parameter to File to effect the state above? (*Is anyone else happy with this?*) 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. >> > Apologies on this non-sequitur. This is sort of spawning the old 'if defined' argument and that way madness lies, so I'm going to stop this before it starts. Thanks, Trevor On Mon, Mar 2, 2015 at 4:21 PM, John Bollinger <john.bollin...@stjude.org> wrote: > > > 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 puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/b26f9b97-c98d-4ed5-b0c7-a09b9e8079fa%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/b26f9b97-c98d-4ed5-b0c7-a09b9e8079fa%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%2BFoXH%3Dkrb0FfL%2BL-XyvLPbNURf1QiFus6osKOtQoC%2Bd-FXA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
