Doug.If a role has a higher precedence than an environment, it sounds like creating a base role with attributes, and then setting attributes in environments would not work at all.If I use the chef-client cookbook as an example, it needs to have the address of the chef server set. If I set that in a role, the 'chef-client' role, then the address of the chef server is not consistent across all locations within that role. Adding a role of 'chef-client' to a node would not adequately capture the fact that in the dev environment it needs to be one thing, while in the prod environment it needs to be something else.Drew,In our case, an environment is pinned to a physical location. For example, our 'dev' and 'qa' environment is located wholly with Amazon AWS us-east-1.--On Thu, Jun 18, 2015 at 11:04 AM, Drew Blessing < " target="_blank"> > wrote:You can create a base role with attributes that apply to all environments. Then set specific attributes in environments. Note that roles have a higher precedence than environments, though.
When you say you're heavily using environments are you overloading the definition of an environment to include locations/datacenter or something? If so, you might be abusing environments :) Roles/role cookbooks or something else might be more appropriate. Something to think about.On Thu, Jun 18, 2015 at 12:48 PM 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-5627
Archive powered by MHonArc 2.6.16.