General discussion about Chef

[chef] Re: Re: Re: Re: Re: Re: Re: Re: Environment Inheritence


Chronological Thread 
  • From: Yoshi Spendiff < >
  • To: chef < >
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Environment Inheritence
  • Date: Thu, 18 Jun 2015 16:20:44 -0700
Yes, but do those nodes run a particular recipe that others don't? Because you can put the override in your recipe, not your cookbook attributes.

Use node.force_override['my']['attribute'] in the recipe code.

Otherwise you can set a node attribute directly as force_override priority.

I feel like you're getting into some sticky territory here that better design can help with...

On Thu, Jun 18, 2015 at 4:02 PM, Douglas Garstang < " target="_blank"> > wrote:
Yoshi.

I can't use force_override in a cookbook as I only want it on nodes matching a certain function (across all environments).

Douglas.


On Thu, Jun 18, 2015 at 3:47 PM, Yoshi Spendiff < " target="_blank"> > wrote:
If you do away with role attributes entirely and put them in role cookbooks then you don't have to use override on environments.

Alternatively you can set this on the nodes directly at force_override or in the recipe itself at force_override if you really have to, although I really would recommend designing your cookbooks in such a way that you don't have to much around with attribute priorities all over the place.

On Thu, Jun 18, 2015 at 3:44 PM, Douglas Garstang < " target="_blank"> > wrote:
I should add that the reason I can't set this attribute at level 13 or 14 is that it should only be set on instances of a certain role, not all instances. I can't set it via an override attribute at position 12 because I don't want all instances in a given environment to receive it.

On Thu, Jun 18, 2015 at 3:26 PM, Douglas Garstang < " target="_blank"> > wrote:
Thanks Galen.

I've already hit a snag with this approach. I'm setting common attributes in a recipe (#2), and overriding environmental attributes in an environment (#12). However, I have a cookbook that needs to modify a single attribute to the openssh cookbook. I don't know where I could put this. There's only 2 places it can go that have higher precedence than #12, and neither of those are a role. :~(

Doug.


On Thu, Jun 18, 2015 at 1:56 PM, Galen Emery < " target="_blank"> > wrote:
Doug,

the levels you suggested are the ones we typically recommend.

The way I teach people is the following:
Cookbook attributes file: use default.
Roles: Use Default
Environments: Use Override.

There's a bunch of other precedence levels and while helpful for debug, can drive you nuts if you're using in production.


On Thu, Jun 18, 2015 at 1:53 PM, Yoshi Spendiff < " target="_blank"> > wrote:
Everything gets merged together. Your attribute set at the end is the result of all levels and locations being merged together and the highest precedence winning.

On Thu, Jun 18, 2015 at 1:49 PM, Douglas Garstang < " target="_blank"> > wrote:
Sounds .... complicated.

I don't think I have a complex enough environment to justify that yet. Looking at the attributes precedence docs, it looks like I could set common attributes as default attributes in a role (#4) and then override with a override attribute in an environment (#12). In this situation though, would the two hashes me merged together?

Doug.

On Thu, Jun 18, 2015 at 1:35 PM, Ranjib Dey < " target="_blank"> > wrote:
oh btw.. i dont use chef's attribute precedence heavily .. most of the attribute customization are spread across standard default precedence level, (recipe, wrappers, environments, roles ), the deep_merge yaml trick. this allows me to bypass most of the so called role-env, role-recipe etc etc patterns, and eases deduction. I still use the higher precedence levels sporadically (like canary releases, CVE patches etc), more like for surgical cases

On Thu, Jun 18, 2015 at 1:30 PM, Ranjib Dey < " target="_blank"> > wrote:
i use environment heavily as well, and face the same problem. The trick i use is have a environments/common folder which container coomon things in yaml file (or ruby if you like) that is just data. Top level environments (say environments/foo.rb) can directly read that yaml, and deep_merge! (one of dans many awesome works :-) ) that directly in default_attributes method. this allows me to keep the common data and reuse it.,

hope that helps.

On Thu, Jun 18, 2015 at 10:48 AM, Douglas Garstang < " target="_blank"> > wrote:
All,

I'm making pretty heavy use of environments. There's quite a fair bit of duplication and I'd like to implement a 'base' environment, with common attributes that apply to all environments. How would I do this?

What happens if the same attribute is defined in multiple environments? Are they merged together or does the 'inherited' one override the 'base' one?

Thanks,
Doug







--



--



--
Galen Emery 



--



--



--



--



--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025

Archive powered by MHonArc 2.6.16.

§