Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources
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. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources
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
Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources
HmmOk, how about this: 1) Dangling symlinks are allowed 2) Warnings on dangling symlinks are the default (because you *probably* don't want them) 3) Setting :force = true, disables the warning message (in theory, you would only do this after seeing the message) 3a) For a less destructive method, something like 'dangle = true' could be allowed I suppose 4) Autorequires happen so that you don't get spurious warning messages Would that work? Thanks, Trevor On Mon, Mar 2, 2015 at 10:10 AM, John Bollinger john.bollin...@stjude.org wrote: On Friday, February 27, 2015 at 2:51:03 PM UTC-6, Trevor Vaughan wrote: Ok, you certainly have a working counter example, but I feel that it *should* actually fail and that this is a bug. [...] 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. I have just demonstrated that dangling symlinks are NOT systematically invalid. They have inherent significance, however limited. In any event, don't lose sight of the fact that resource relationships are strictly about *order of application*, not about semantic associations between resources. The validity of a symlink in light of other elements of the state of the system is a resource-relationship concern only to the extent that it affects whether the symlink or other resources can be applied. Whether a dangling link is acceptable or wanted is an entirely separate issue. It is, moreover, a good general idea to minimize the number of resource relationships by avoiding unneeded ones. Although a relationship *is* needed (to ensure a viable order of application) in the case described in PUP-4036, that's unusual and case-specific. It should also be readily visible to the manifest author, and easily fixable without changes to Puppet. Thinking about this further, should Puppet even be able to create invalid symlinks? Of course it should be able to do. Puppet is my tool, not my nanny. If the target system allows dangling symlinks then Puppet has no good reason to go out of its way to make it difficult to create them. It doesn't know and shouldn't be expected to guess whether it's intentional, acceptable, or wrong for any particular link to dangle at any given time. I'd be ok with warnings about dangling links, though, which potentially Puppet could emit even when the link is already in sync. 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. Can we at least have consistency? If Puppet accepts dangling symlinks as a valid, in-sync target state for existing resources, then it should not refuse to manage resources into such a state. On the other hand, if Puppet is unwilling to manage a symlink into a dangling state, then it should not accept an existing dangling symlink as being in sync. 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/5e3447ea-8ebe-4cfa-85df-56decb5506d4%40googlegroups.com https://groups.google.com/d/msgid/puppet-dev/5e3447ea-8ebe-4cfa-85df-56decb5506d4%40googlegroups.com?utm_medium=emailutm_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%2BFoUuTqXmpXbCDUzEEQ-uJ0HVvXDq9wq5ew-XMpuoUgiZ6w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources
On Friday, February 27, 2015 at 2:51:03 PM UTC-6, Trevor Vaughan wrote: Ok, you certainly have a working counter example, but I feel that it *should* actually fail and that this is a bug. [...] 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. I have just demonstrated that dangling symlinks are NOT systematically invalid. They have inherent significance, however limited. In any event, don't lose sight of the fact that resource relationships are strictly about *order of application*, not about semantic associations between resources. The validity of a symlink in light of other elements of the state of the system is a resource-relationship concern only to the extent that it affects whether the symlink or other resources can be applied. Whether a dangling link is acceptable or wanted is an entirely separate issue. It is, moreover, a good general idea to minimize the number of resource relationships by avoiding unneeded ones. Although a relationship *is* needed (to ensure a viable order of application) in the case described in PUP-4036, that's unusual and case-specific. It should also be readily visible to the manifest author, and easily fixable without changes to Puppet. Thinking about this further, should Puppet even be able to create invalid symlinks? Of course it should be able to do. Puppet is my tool, not my nanny. If the target system allows dangling symlinks then Puppet has no good reason to go out of its way to make it difficult to create them. It doesn't know and shouldn't be expected to guess whether it's intentional, acceptable, or wrong for any particular link to dangle at any given time. I'd be ok with warnings about dangling links, though, which potentially Puppet could emit even when the link is already in sync. 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. Can we at least have consistency? If Puppet accepts dangling symlinks as a valid, in-sync target state for existing resources, then it should not refuse to manage resources into such a state. On the other hand, if Puppet is unwilling to manage a symlink into a dangling state, then it should not accept an existing dangling symlink as being in sync. 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/5e3447ea-8ebe-4cfa-85df-56decb5506d4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources
On Monday, March 2, 2015 at 7:21:55 AM UTC-8, Trevor Vaughan wrote: HmmOk, how about this: 1) Dangling symlinks are allowed 2) Warnings on dangling symlinks are the default (because you *probably* don't want them) 3) Setting :force = true, disables the warning message (in theory, you would only do this after seeing the message) 3a) For a less destructive method, something like 'dangle = true' could be allowed I suppose 4) Autorequires happen so that you don't get spurious warning messages Would that work? It still seems presumptuous to me even to emit warnings by default if Puppet creates a symlink which is dangling at the time of creation. The assumption is that potential benefit of the alert would outweigh the cost of the potential noise and extra parameters required to silence it when dangling symlinks are desired. Besides the crazy things symlinks get used for on occasion, such as Samba's use of dangling symlinks to represent DFS file shares https://wiki.samba.org/index.php/DFS, Puppet may legitimately be asked to create a link prior to installing a package or performing another action which will result in the target being created, and users shouldn't need to set :force or :dangle for their first run to log cleanly. The potential benefit of the noise does not merit the extra complexity to silence it. This is an instance where Puppet cannot reasonably determine whether or not a dangling symlink is a problem and should not presume to do so. -- 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/1f9719c7-3729-4311-b93f-c386408f1e6d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources
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 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. 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'd much rather be able to shim in my own auto* items from the DSL (I mean, it's an Array), but this goes back to the 'if defined considered harmful' argument which, in turn, spawns John's Puppet's not my Nanny argument. Good conversation and idea flow throughout! Thanks, Trevor On Mon, Mar 2, 2015 at 1:29 PM, Reid Vandewiele r...@puppetlabs.com wrote: On Monday, March 2, 2015 at 7:21:55 AM UTC-8, Trevor Vaughan wrote: HmmOk, how about this: 1) Dangling symlinks are allowed 2) Warnings on dangling symlinks are the default (because you *probably* don't want them) 3) Setting :force = true, disables the warning message (in theory, you would only do this after seeing the message) 3a) For a less destructive method, something like 'dangle = true' could be allowed I suppose 4) Autorequires happen so that you don't get spurious warning messages Would that work? It still seems presumptuous to me even to emit warnings by default if Puppet creates a symlink which is dangling at the time of creation. The assumption is that potential benefit of the alert would outweigh the cost of the potential noise and extra parameters required to silence it when dangling symlinks are desired. Besides the crazy things symlinks get used for on occasion, such as Samba's use of dangling symlinks to represent DFS file shares https://wiki.samba.org/index.php/DFS, Puppet may legitimately be asked to create a link prior to installing a package or performing another action which will result in the target being created, and users shouldn't need to set :force or :dangle for their first run to log cleanly. The potential benefit of the noise does not merit the extra complexity to silence it. This is an instance where Puppet cannot reasonably determine whether or not a dangling symlink is a problem and should not presume to do so. -- 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/1f9719c7-3729-4311-b93f-c386408f1e6d%40googlegroups.com https://groups.google.com/d/msgid/puppet-dev/1f9719c7-3729-4311-b93f-c386408f1e6d%40googlegroups.com?utm_medium=emailutm_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%2BFoV4MEKDrF-btfjdGzYVEFQDKpQ1j3%3D7364fgc76rivGSQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
