On Oct 27, 2:35 pm, Stefan Schulte <stefan.schu...@taunusstein.net> wrote: > On Thu, Oct 27, 2011 at 08:00:05AM -0700, David Campos wrote: > > Hello all, > > > I am facing a problem while dealing with a custom provider and its > > requirements. I have included a custom provider (with its custom > > types) into my puppet deployment that is expected to deal with all > > tasks related to glassfish. This provider is able to create domains, > > deploy applications and other features. > > > This provider also requires a glassfish executable named 'asadmin' > > that is available after glassfish is installed. If the executable is > > available at the machine where agent is executed all works fine but if > > it is not available a message like '[default] ←[0;37mdebug: > > Puppet::Type::Domain::ProviderAsadmin: file asadmin does not exist←[0m > > Could not find a default provider for domain' is returned. > > > All that behaviour is normal since there are not alternative providers > > for my resources and then the provider is not appliable but the > > problem appears when I want to install the application AND THEN work > > with the provider. In the theoretical scenario, puppet should install > > glassfish, deal with path and finally do some work with the provider > > but the real scenario is not that. The real scenario is that puppet > > does a prefetch of all resources that deal with providers and tries to > > load them. Since 'asadmin' is not yet available, the execution fails. > > > Do anyone knows any way to let puppet skip that (or delay it until > > glassfish has been installed) and finish successfully? Would stages do > > a trick here? The only workaround that I have found has been perform > > the installation in a first provision and then, at the second > > provision, deal with resources. > > > Scenario: > > - Install Glassfish > > - Configure Glassfish > > - Deal with resources (provider) > > Stages does not change a thing. At first I would suggest you > watchhttps://projects.puppetlabs.com/issues/6907 > > I can see three possibilities: > > - write a dummy provider that doesn't do anything but also doesn't need > anything. > During the first puppet run puppet will pick the dummy provider. When > you run puppet the next time your glassfish binary is already > installed and puppet can choose between two providers. IIRC puppet > tries to pick the one that is the most specific and that is the one > with the most confines (so in your case it will probably work as > desired) > - use optional_commands :foo => '/bin/foo' instead of commands :foo => > '/bin/foo'. This way the provider is still suitable even if your binary is > not installed. But prefetching will fail on the first run (but puppet > should apply the catalog so the second run should work ok) > - use a custom fact that tells you if the binary of your provider is > installed. Wrap each resource in your manifest in an if clause. Now > you also need two puppet runs but the first run does not throw an > error.
I think Stefan has covered the field pretty well. Personally, I don't much like the dummy provider, though: it will prevent the error message, but because it doesn't actually do anything, it lies to the Puppet agent whenever it claims to have synchronized a resource. This may cause dependent resources to fail, and it results in two runs being required to achieve the target state, if that's an issue. The optional_commands approach is pretty smooth, and the prefetch problem is only relevant if it's possible for there to be existing resources when the needed binary is not already present. If you can use some alternative mechanism to prefetch resources then there doesn't have to be a prefetching problem at all. If you make the provider a do-nothing in the event that asadmin is missing then this option becomes a superset of the dummy provider option; that would allow you to avoid multiple providers. (I still don't like the dummy option even when implemented this way, however: better to fail a resource if asadmin is not available when the time comes to sync it.) The custom fact approach is pretty easy to add on top of your existing provider and manifests. Also, if you arrange your resources suitably then you should be able simply to conditionally include an entire class, instead of conditionally declaring each of several separate resources. John -- 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.
