On Mar 28, 12:49 pm, Justin Ellis <[email protected]> wrote: > On Mon, Mar 28, 2011 at 10:49 AM, Patrick <[email protected]> wrote: > > > On Mar 27, 2011, at 11:10 PM, Justin Ellis wrote: > > > Good Evening! > > > I'm having issues with the order in which items are ran inside of a service > > class, it's attempting to run before the provider is present (the provider > > is provided by the glassfish package). It looks for the glassfish provider > > prior to inheriting the repository or the package list. > > >http://snipt.org/woomg > > > I have included a snipt of the code, does anyone have an idea as to what > > I'm missing? > > > Providors are only reloaded at the beginning or a run and right after > > pluginsync, so installing your provider using "package" won't work like you > > want. Solutions: > > > 1) Push it out using pluginsync > > 2) Do it in 2 runs (I think this will work, but the client might refuse to > > continue when it sees that it doesn't have the type glassfish) > > 3) Install glassfish in whatever script installs puppet. > > Sorry, I guess I should have prefaced this. The types are pushed out via > pluginsync and exist on the clients, it's moreso that the binary the types > reference is installed via a package. The glassfish package has to be > installed in order for the types to exist. > > Does that clear it up any?
Yes, some. The Puppet debug-level output from the client, showing the error message, would complete the picture. At a guess, however, the provider checks for the presence of the required binary early, as part of the process of determining whether it is applicable to the client. Depending on how you wrote the provider, the Puppet infrastructure may be doing that for you. As I understand it, providers are bound to all resources before any resources are applied. If I have diagnosed that correctly, then in addition to Patrick's options (2) and (3), you also have (4) Modify the provider to assume the presence of the required glassfish binary instead of checking for it first. This would be a big kludge, and I mention it only for completeness. (5) Rewrite the "glassfish" type as a Puppet define. I know it hurts to abandon code that almost or mostly works, but it sounds like "glassfish" probably ought to have been a define all along. Remember: for all intents and purposes, a define is a custom type written in Puppet DSL instead of in Ruby. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
