[chef] Re: Environment Inheritence

["Brian O'Connell" < >]

Doug -

  We ran into the same thing and ended up rolling our own solution..  We keep our reusable parts of the environment in separate json files.  We then have one yaml file that describes the merge order and any attribute overrides necessary for that final environment.  The items in the override attributes take precedence over anything in the merged_from files.

 

So for example, here is a snippet with placeholders '<>' in place of actual environments from our environments.yml:

 

environments:

- name: <security_zone>_<application_zone>_<datacenter>
  description: <Description here>
  override_attributes:
    name_resolution:
      nameservers: ['<value1'>, '<value 2>']
      extra_search_domains: ['<value1>','<value2>']
  merged_from:
     - <security_zone>.json
     - <application_zone>.json
     - <datacenter>.json

 

Application zone is normal things like pre, prod, test, etc.

 

We then have about 20 lines of ruby that do a deep merge on the json files and they are merged in the order you specify.  When it is done, it spits out our 30+ different environments which we can upload  into our chef server.

 

This works well for us because we have a lot of environment combinations that share enough common attributes, but need to be different for many reasons.

 

-
Brian O'Connell, STSM
Master Inventor, Cloud Services
IBM - Continuous Availability Services
 

 

----- Original message -----
From: Douglas Garstang < >
To:
Cc:
Subject: [chef] Environment Inheritence
Date: Thu, Jun 18, 2015 1:48 PM
 

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