[chef] Re: Re: Confused about environments.

[Douglas Garstang < >]

Larry,

Thanks. I understand all that.

At the time, this statement from the documentation made perfect sense given that in our environment we have one git repo per chef repo.

"A Ruby file for each non-default environment must exist in the environments/ subdirectory of the chef-repo. "

I since have realised thats' not quite true. In any case, roles and environments both don't address the fact that if I define a common attribute in a role or an environment, that is used by multiple cookbooks, and I change that attribute name, all the cookbooks that refer to it will break.

This is why I wanted to contain the attribute (and all it's 'environments' solely within the cookbook. 

For example, let's say I define this in a role somewhere.

"mysql_server": {

    'US1": "server1",

    "US2": "server2",

    "EU1": "server3",

    ....

}

Now lets also say 5 cookbooks use this attribute. Change "mysql_server" to "mysql_host" and those cookbooks all break. Instead, if each cookbook defined it's own reference to the mysql server for each location, changing one would not break any others. Following this approach would seem to make cookbooks a lot less brittle at the expense of a little more duplication of data.

Until recently I thought test kitchen couldn't use roles. Maybe it can now. I need to check that. Putting the attributes into the cookbook would also seem to make test kitchen more reliable, as the attributes would come directly from the cookbook. You wouldn't need to copy and paste them from a role.

Doug.

Doug

On Fri, Feb 14, 2014 at 8:05 PM, Larry Wright < " target="_blank"> > wrote:

Hi Doug,

Environments are solely global in nature, so that file needs to go in your top-level environments directory (and uploaded to your Chef server). I think you’re looking at them backwards. Environments are containers (think development, staging, production) where you may want to have different versions of a cookbook, or different attributes. Typical use cases are things like having a different set of hostnames or credentials that you use in staging vs. production, or locking your production environment to a specific version of a cookbook so that you don’t inadvertently release something before it’s been tested thoroughly. 

This presentation by Seth Vargo may help clear it up, but feel free to ask more questions if I didn’t explain it well enough: https://speakerdeck.com/sethvargo/chef-plus-environments-equals-safer-infrastructure

-- 
Larry Wright

@larrywright

On February 14, 2014 at 3:41:09 PM, Douglas Garstang ( " target="_blank"> ) wrote:

I'm missing an important detail with chef environments. I created an environment called 'eu2-prod' with the knife command, and can view and edit it.

In my cookbook I have created the environments directory into which I have deposited an environment file called 'eu2-prod.json'. It looks like this:

{

  "name": "eu2-prod",

  "description": "",

  "cookbook_versions": {

  },

  "json_class": "Chef::Environment",

  "chef_type": "environment",

  "default_attributes": {

  },

  "override_attributes": {

  }

}

All this has been uploaded to the chef server. However, when the client runs, it can't find the data from the eu2-prod environment. 

Looking at the chef GUI, I'm still confused. The cookbook itself doesn't show the environments/ directory, but rather has a drop-down at the top which lets me select which environment I am looking at. No matter which environment I pick, 'None', '_default' or 'eu2-prod' I can't see any of the data from the environments/eu2-prod.json file.

If I go over to the Environments global section in the UI, also there's no data there. I wouldn't expect to see any data there anyway, as I imagine that's environment data that's, err... global in scope. 

Thanks,

Doug

--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: ">
Cell: +1-805-340-5627