This is a lot nicer than the existing workarounds using ensure_resource and defined. Previously I was thinking about something along similar lines but with slightly different behavior. I was thinking of some mechanism whereby if you define a constraint then it will be autorequired *if* it is in the catalog, then the provider will use the RAL to determine the currently configured state and throw a meaningful error if its not configured.
This opens up the posibility of adding a pre-req, but not enforcing that the resource is managed through Puppet. Eg: if someone isn't managing a package resource in Puppet because it's part of the base OS install, then the pre-req will still pass because it exists. If it's a Puppet managed resource it will be autorequired and therefore will exist before the provider quieres the RAL. I couldn't find an easy way to do dynamic autorequires this way so gave up on it a bit. I like what you've done here though, I'll have a play with it soon. Craig On Sat, May 3, 2014 at 10:48 PM, Felix Frank < [email protected]> wrote: > Hi, > > hoping to reach some of the more prolific module authors via this list, > I'm most pleased to announce the initial release of the constraints > module at > > https://forge.puppetlabs.com/ffrank/constraints > > I shall try and reach even more authors via the users' list in time, but > if some early adopters could take this for a spin, we may be able to > iron out some quirks even before that. > > As for the general support of this idea - there is currently a PR for > puppet proper to add native support for types that pre-validate the > whole catalog. In the meantime, the module does support current versions > back to 2.6.x (using a clean workaround). I don't expect a merge of the > constraint functionality into the core before the Puppet 4 release, but > this ultimately depends on the overall resonance in the community. > > TL;DR thanks in advance for using constraints in your modules and > providing feedback. > > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/53656437.1010602%40Alumni.TU-Berlin.de > . > For more options, visit https://groups.google.com/d/optout. > -- *Enviatics *| Automation and configuration management http://www.enviatics.com | @Enviatics Puppet Training http://www.enviatics.com/training/ -- 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/CACxdKhHXGQ%3D0jf_U_za6XoQJauVFJ-AJP5Zn%2By0Fe5JxOUAFQw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
