[chef] Re: Re: Re: Re: Best practices for modifying standard cookbooks

[AJ Christensen < >]

Hmm, LWRPs within LWRPs are fickle in this regard, I don't believe that it's possible to access the interior resource from the outer contexts during compile phase. Even moreso, the resources created during actions specified by providers are run in separate run contexts again -- you're talking about accessing the interior resources (deploy) of an app specific provider (application_ruby?), two run contexts deep of the original application LWRP.

Maybe someone can speak more to the internals of this -- perhaps there is a way to share the contexts back upward in some kind of crazy inception scenario.

I'd suggest we add node attributes to control the shallow clone setting you speak of as a quick fix, as these won't need to be controlled with rewind or re-opening resources.

--AJ

On 24 November 2012 17:20, Leo Dirac (SR) < " target="_blank"> > wrote:

Thanks for the tip -- that seems like a useful tool to put in my chef toolbox.  But I'm not quite sure how to use it here since it's not a template I need to modify.  I think it's a LWRP setting options for another LWRP -- the application provider calling into the git provider.  Can chef-rewind help there?

On Fri, Nov 23, 2012 at 1:26 PM, Bryan Berry < " target="_blank"> > wrote:

thanks for mentioning rewind AJ!

w/ rewind u can do it like this

rewind "template[name_of_template]" do

    variables(:some_param => "new_value")

end

same thing as AJ describes just pretty

On Fri, Nov 23, 2012 at 9:53 PM, AJ Christensen < " target="_blank"> > wrote:

You can re-open resources during compile phase. Bryan W. Berry has released a gem that adds some syntactic sugar to the Recipe [0]

```

thing_to_edit = resources(:template => "name_of_template")

thing_to_edit.cookbook_name "another_cookbook"

thing_to_edit.variables thing_to_edit.variables.merge(:another_param => "some val")

```

Cheers,

AJ

[0]: https://github.com/bryanwb/chef-rewind

On 24 November 2012 09:47, Leo Dirac (SR) < " target="_blank"> > wrote:

I'm getting ready to update to the new version of the application cookbook, and I'm seeking advice for carrying forwards a custom modification I made.

My issue comes from the application cookbook always doing a "shallow clone" of a git repo (source), which on my systems sometimes causes a failure to deploy.  Last time I fixed this by just changing that line of code from "true" to "false" in my local cookbook.  It's expedient, but doesn't seem like a best practice, and forces me to re-do this kind of change every time I upgrade.

How do others manage customizations to shared cookbooks?

Thanks!