On Thursday, February 25, 2016 at 7:45:46 PM UTC-6, Trevor Vaughan wrote: > > Sorry about that. > > What I mean is this: > > A -> [] -> B is not equivalent to A -> B since failures in A will not > affect B. > > However, it would be equivalent to [A,B] which I am reading as A before B > but not in an actual resource relationship. >
Now you're confusing me. Chain expressions are a means for declaring resource relationships. To the extent that failures of resources earlier in a chain prevent resources later in the same chain from being applied, that is a function of the resource relationships expressed by the chain. If the chain A -> [] -> B does express a direct or transitive relationship between A and B then failures in A prevent B from being applied. If that chain does not express any relationship between A and B then it does not constrain their order of application. It sounds, however, as if you are asking for an altogether new kind of ordering constraint, one which directs order of application but allows resources to be applied despite the failure of resources constrained to be applied earlier. If that's so, then I'm afraid I don't see the point. If a resource B can by synced successfully despite another resource A failing to sync, then how can it matter whether the attempt to sync A is made before the attempt to sync B? If indeed that's what you're asking for, however, then rather than create a new kind of relationship, I think it would be better to create a way to declare that application of specific containers always succeeds or always fails, regardless of the outcome of applying whatever is declared within. Then you could wrap resource A in a container (e.g. a define) that succeeds whether A succeeds or not, and establish an ordinary relationship between that container and B. I'm inclined to think that there would be other uses for such a feature, and rather than any new DSL syntax, the DSL interface to it could be implemented as a function. 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/9a05acc5-cd89-48d8-90d5-5b2a9cd8cd35%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.