Passing blocks as LWRP attributes

Benton_Roberts · December 4, 2012, 4:26pm

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

Jay_Feldblum · December 4, 2012, 4:34pm

Benton,

github.com

chef/chef/blob/10.16.2/chef/lib/chef/resource/deploy.rb

#
# Author:: Daniel DeLeo (<dan@kallistec.com>)
# Author:: Tyler Cloke (<tyler@opscode.com>)
# Copyright:: Copyright (c) 2008 Opscode, Inc.
# License:: Apache License, Version 2.0
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#

# EX:

This file has been truncated. show original

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

kallistec · December 4, 2012, 4:37pm

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