Passing blocks as LWRP attributes


#1

Ohai, chefs!

I am trying to write a LWRP that “wraps” the Opscode deploy_revision Provider to add some organization-specific functionality. The LWRP sets some organization-wide defaults, defines some supporting Chef Resources, and then defines the usual Opscode deploy_revision Resource. Many of the attributes for my LWRP simply pass their values through to the deploy_revision Resource, exactly as one would expect:

deploy_revision app_name do
revision new_resource.revision
repository new_resource.repository
migration_command new_resource.migration_command
enable_submodules new_resource.enable_submodules
…[and so on]

This works fine for simple value attributes like those listed above, but does not seem to work for the block attributes: before_migrate, after_symlink, etc. Using the same syntax (a regular “do…end” statement passed as an argument to the LWRP’s before_migrate method) just yields a value of nil for “new_resource.before_migrate”.

Is there a way to pass blocks to an LWRP, and then pass them onto deploy_revision so that the blocks get invoked in the same context (i.e. “releases_dir”)? How would you handle this situation?

Thanks in advance,

  • benton

Benton Roberts
benton@bentonroberts.com


#2

Benton,

Cheers,
Jay

On Tue, Dec 4, 2012 at 11:26 AM, Benton Roberts benton@bentonroberts.comwrote:

Ohai, chefs!

I am trying to write a LWRP that “wraps” the Opscode deploy_revision
Provider to add some organization-specific functionality. The LWRP sets
some organization-wide defaults, defines some supporting Chef Resources,
and then defines the usual Opscode deploy_revision Resource. Many of the
attributes for my LWRP simply pass their values through to the
deploy_revision Resource, exactly as one would expect:

deploy_revision app_name do
revision new_resource.revision
repository new_resource.repository
migration_command new_resource.migration_command
enable_submodules new_resource.enable_submodules
…[and so on]

This works fine for simple value attributes like those listed above, but
does not seem to work for the block attributes: before_migrate,
after_symlink, etc. Using the same syntax (a regular “do…end” statement
passed as an argument to the LWRP’s before_migrate method) just yields a
value of nil for “new_resource.before_migrate”.

Is there a way to pass blocks to an LWRP, and then pass them onto
deploy_revision so that the blocks get invoked in the same context (i.e.
“releases_dir”)? How would you handle this situation?

Thanks in advance,

  • benton

Benton Roberts
benton@bentonroberts.com


#3

On Tuesday, December 4, 2012 at 8:26 AM, Benton Roberts wrote:

Ohai, chefs!

I am trying to write a LWRP that “wraps” the Opscode deploy_revision Provider to add some organization-specific functionality. The LWRP sets some organization-wide defaults, defines some supporting Chef Resources, and then defines the usual Opscode deploy_revision Resource. Many of the attributes for my LWRP simply pass their values through to the deploy_revision Resource, exactly as one would expect:

deploy_revision app_name do
revision new_resource.revision
repository new_resource.repository
migration_command new_resource.migration_command
enable_submodules new_resource.enable_submodules
…[and so on]

This works fine for simple value attributes like those listed above, but does not seem to work for the block attributes: before_migrate, after_symlink, etc. Using the same syntax (a regular “do…end” statement passed as an argument to the LWRP’s before_migrate method) just yields a value of nil for “new_resource.before_migrate”.

Is there a way to pass blocks to an LWRP, and then pass them onto deploy_revision so that the blocks get invoked in the same context (i.e. “releases_dir”)? How would you handle this situation?

Thanks in advance,

  • benton

Benton Roberts
benton@bentonroberts.com (mailto:benton@bentonroberts.com)

I’m guessing you need to “blockinate” your blocks, which means use code like this:

before_migrate &new_resource.before_migrate # note the ampersand

This is because ruby treats blocks as both regular objects and also a special thing. This blog post may be of use:


Daniel DeLeo