On Wed, Oct 05, 2011 at 07:50:48AM -0700, Luke Bigum wrote: > My explanation's not the best so went looking to see if the Internals > wiki page specifically mentions what I'm talking about, I'm pretty > sure the problem is in the Parsing phase: > > http://docs.puppetlabs.com/guides/puppet_internals.html > > On Oct 5, 3:42 pm, Luke Bigum <luke.bi...@lmax.com> wrote: > > 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.
I decidedly hadn't thought this through -- custom types/facts aren't part of the catalog, and run stages are only for catalog items. I certainly appreciate the explanation! > > 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-vcsrepotocheckout > > > > > 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. > > -- 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.
