On Mon, Apr 14, 2014 at 10:23 PM, Felix Frank < felix.fr...@alumni.tu-berlin.de> wrote:
> On 04/15/2014 03:01 AM, Andy Parker wrote: > > I'm wondering if there is a way of either doing this in a module (do > > the constraint check in a provider), or if there is a change we can > > make to allow this to be in a module. It would be great to be able to > > have the extension points so that these kinds of things don't have to > > go into the puppet repository in order to be tried out. > > Thanks for the input. > > I even *had* been thinking of hacking the constraint evaluation into the > new type's generate hook. This way, the agent would naturally run them > before the transaction, thinking it was a constraint's way to do > generate additional resources. > > Generate might the appropriate place, or some new hook that we don't have yet. There has been a constant need for lifecycle hooks so that providers can make better decisions. > This has two limitations, though: > 1. The cosmetic issue that the error output alludes to the generation of > additional resources and > 2. the critical problem that this hook has no way to interrupt the > transaction. > > Usually, exceptions that are raised from types and providers are handled > as "resource local" problems. They will fail the resource, but not the > transaction as a whole. > > Right, and if this fails it needs to show up in the report, so that also needs to be taken into account. > I currently see no way to do this without patching the transaction code. > Of course, we could just introduce an appropriate hook into the core and > do everything else in modules for a time then. > > Yep, that is what I was thinking. I think some functionality like this would be great to have in the core, but I'd like to make sure that it is proven a bit outside first. If that means that we need to make some changes to the core to add the hooks that are needed, then I actually see that as a win-win: not only do we get this awesome functionality out there and able to be iterated on faster than puppet releases, but we also get some extra hooks to make this kind of stuff easier/possible in the future for others. > Seeing as the lonterm goal of the feature would be to serve as the > mortar between third party modules, I'd still see it in tier 1, but > that's just my gut feeling. > > It may just become a very common dependency such as concat_file I guess. > But can we deprecate defined() in favor of an external module? :-) > > Nope :) But I'd like to make sure that this not only solves the defined() problem, but is a joy to use and has powerful features, which might take a little trial and error. > Cheers, > Felix > > -- > 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/534CC263.2070403%40Alumni.TU-Berlin.de > . > For more options, visit https://groups.google.com/d/optout. > -- Andrew Parker a...@puppetlabs.com Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014 <http://www.puppetconf.com/>, September 22-24 in San Francisco* *Register by May 30th to take advantage of the Early Adopter discount <http://links.puppetlabs.com/puppetconf-early-adopter> **—**save $349!* -- 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/CANhgQXudtp4zx0QCFH2%3DPc%3DWbJu385H0enp3CdGjQ%2BTfqAT_Ow%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
