[chef] Re: Re: Re: Re: Re: deep merge - !merge users


Chronological Thread 
  • From: Jay Feldblum < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: deep merge - !merge users
  • Date: Thu, 8 Dec 2011 11:22:39 -0500

Imagine a cookbook for implementing firewall rules, which inspected the node attributes to discover the rules, and was expected to be configured via roles. One role might want to append a rule, where each rule can include multiple source and destination interfaces, ip-addresses, protocols, port ranges, etc. Another node might want to append another rule, and a third role might want to update the first rule by appending e.g. an additional port range.

Imagine the application or database cookbooks were implemented differently, where they inspected node attributes rather than searched data bags. The configurations for these are rather complex. Then one role might want to add a some data, while another role might want to update it; the first role providing blanket/default data, the second role being application-specific.

Imagine fnichol's chef-rvm cookbook had default attributes that you don't like. You want your role to add the cookbook to the run-list but delete those default attributes, for example, delete the nested attribute that says ruby vX should be installed by default or gem Y should be installed by default in each ruby.

- Jay Feldblum

On Thu, Dec 8, 2011 at 10:45 AM, Bryan McLellan < "> > wrote:
On Thu, Dec 8, 2011 at 10:03 AM, Jay Feldblum < "> > wrote:
> But it is helpful when it comes to reusing third-party cookbooks: it permits
> writing custom roles to control and integrate with complex generic
> third-party cookbooks which look at deep attributes structures to decide
> what to do.

Could you provide a specific example for others to follow to understand?

Bryan




Archive powered by MHonArc 2.6.16.

§