Not exactly. If we could both get our resources to fail individually (like a File's "source" parameter not existing and throwing an error for that resource) it would work, but because we're using custom types, the Puppet agent loads all those in (and Facts) and dies before it gets to it's catalog, so run levels won't help. It's the same error as if you went to use a native Augeas resource and didn't have the Augeas Ruby bindings installed.
On Oct 5, 3:36 pm, Christopher Wood <christopher_w...@pobox.com> wrote: > Without waving my ignorance around too much... does Matthias' issue fit run > stages? This sounds like exactly what they were designed to solve: ensure > certain things definitely happen before certain other things. > > > > > > > > On Wed, Oct 05, 2011 at 07:33:29AM -0700, Luke Bigum wrote: > > Matthias, > > > I had a similar problem recently with libvirt Ruby bindings being > > required for a provider. Due to a few other requirements I opted for > > creating a "second pass" approach by using a custom fact to describe > > whether my provider was "ready to be used" on a node and wrap my > > resources in a conditional based on this fact. The fact tests certain > > files exist which are installed by packages managed in other Puppet > > modules. It's pretty hacky but I didn't have time to invest in a nicer > > solution such as handling the error inside the provider. > > > -Luke > > > On Oct 5, 3:25 pm, Matthias Pigulla <m...@webfactory.de> wrote: > > > Hi all, > > > > I have repeatedly encountered the problem that I would like Puppet to > > > install a particular piece of software, for example git, and then use a > > > provider likehttps://github.com/puppetlabs/puppet-vcsrepotocheck out a > > > repository. > > > > This fails with a message like "Could not run Puppet configuration > > > client: Could not find a default provider for ..." unless the tool (git, > > > to stick with my example) is already installed. This chicken and egg > > > problem applies to some other install-stuff-and-do-more-stuff-with-it > > > situations as well. > > > > I understand that it would be way too complicated for puppet to be able > > > to handle all this in a single run. But isn't failing due to the lack of > > > a particular (default) provider too hard? > > > > If Puppet would carry on and just fail on the vcsrepo {} (or whatever > > > type of resource), things would probably sort out after two or three > > > agent runs. > > > > In IRC they pointed me to either using environments, which I think is too > > > complicated (having to maintain "bootstrap" and "production" manifests). > > > > Another tip was to have a look at the way the pip package provider > > > (https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/...) > > > works, see lazy_pip at the end. But to me it seems as if that would be > > > out of line with the rest of providers and working against the API > > > provided by Puppet. > > > > Suggestions? > > > > -mp. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
