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:Doug.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. :~(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 DefaultEnvironments: 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:Doug.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?--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 casesOn 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:Thanks,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?All,
What happens if the same attribute is defined in multiple environments? Are they merged together or does the 'inherited' one override the 'base' one?
DougRegards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: " target="_blank">
Cell: +1-805-340-5627Galen Emery
--Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: " target="_blank">
Cell: +1-805-340-5627
--Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: " target="_blank">
Cell: +1-805-340-5627
Archive powered by MHonArc 2.6.16.