On Friday, December 21, 2012 at 2:54 PM, Maven User wrote:
Am I missing something?It also seems to run some of the steps out of order (right above this block in the provider is an unzip step which now is run AFTER the Dir bit...).Hmmm - some new weirdness...The first time a recipe is run that is using this provider, that evaluates to nothing, so the subsequent lines are skipped.
I have a block of ruby code like this in the provider:
Dir["/srv/#{new_resource.artifactid}-#{new_resource.version}/templates/**/*"].each do |file|
puts "here is the file #{file}"
....
Short: This is basically the LWRP version of the compile/converge phase issue. Use action :nothing and run_action to make resources execute immediately.Long:LWRPs currently handle nested resources by inserting them in the top-level resource collection *after* the LWRP's position in the resource collection. For a recipe like this:resource_onelwrp_resource -> sub_resource_one, sub_resource_tworesource_three…after lwrp_resource is converged, your resource collection looks like:resource_one #already executedlwrp_resource #already executedsub_resource_onesub_resource_tworesource_threeThis implementation was chosen so that the "sub resources" within an LWRP could notify resources outside of the LWRP. The downside is that the LWRP resource itself cannot properly determine if it was updated or not. See:In either of the "insert after" or "inline recipe" implementations, you'll still have the general compile/converge pattern, which means that raw ruby code that's not wrapped in a ruby block will execute *before* resources, unless you force the issue with #run_action.Another option for implementing LWRPs would be to scrap the compile/converge distinction altogether, but then notifications are pretty much impossible, which makes anything that wants to trigger an execute resource based on something else being updated (like a config file) much more difficult to write.--Daniel DeLeo
Archive powered by MHonArc 2.6.16.