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
A node can only have one environment. I'm not sure you'd be able to create
a 'base' environment or, even if you could, if it would be recommended.
I'd recommend setting good defaults in your cookbooks and then overriding
those using attributes in environments.
On Thu, Jun 18, 2015 at 1:48 PM, Douglas Garstang doug.garstang@gmail.com
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
Nathan,
I'm making heavy use of community cookbooks. As such there isn't a cookbook
I can place attributes in, in most cases. Unless, I start wrapping just to
set attributes in a cookbook, which doesn't make sense to me.
Douglas.
On Thu, Jun 18, 2015 at 10:52 AM, Nathen Harvey nharvey@chef.io wrote:
A node can only have one environment. I'm not sure you'd be able to
create a 'base' environment or, even if you could, if it would be
recommended.I'd recommend setting good defaults in your cookbooks and then overriding
those using attributes in environments.On Thu, Jun 18, 2015 at 1:48 PM, Douglas Garstang <doug.garstang@gmail.com
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
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
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 doug.garstang@gmail.com
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
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 <doug.garstang@gmail.com>
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
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.
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.
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.
Doug.
On Thu, Jun 18, 2015 at 11:04 AM, Drew Blessing drew@blessing.io 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
something else might be more appropriate. Something to think about.
On Thu, Jun 18, 2015 at 12:48 PM Douglas Garstang doug.garstang@gmail.com
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
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
Roles and Environments have two attribute levels available, default and
override, so you can do overrides either way.
In the setup here we use common or default attributes in a role cookbook
and then set any environment specific overrides in an environment. That way
there are no duplicated values in environments.
On Thu, Jun 18, 2015 at 11:24 AM, Douglas Garstang doug.garstang@gmail.com
wrote:
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.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.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.Doug.
On Thu, Jun 18, 2015 at 11:04 AM, Drew Blessing drew@blessing.io 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
something else might be more appropriate. Something to think about.
On Thu, Jun 18, 2015 at 12:48 PM Douglas Garstang <
doug.garstang@gmail.com> 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--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com
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 doug.garstang@gmail.com
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
Yoshi,
So, you basically have a role called common-env (or whatever), set common
attributes there, and then include the common-env in your run list as well
as the functional (ie web-server, apache-server etc) role?
Douglas.
On Thu, Jun 18, 2015 at 12:52 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:
Roles and Environments have two attribute levels available, default and
override, so you can do overrides either way.In the setup here we use common or default attributes in a role cookbook
and then set any environment specific overrides in an environment. That way
there are no duplicated values in environments.On Thu, Jun 18, 2015 at 11:24 AM, Douglas Garstang <
doug.garstang@gmail.com> wrote: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.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.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.Doug.
On Thu, Jun 18, 2015 at 11:04 AM, Drew Blessing drew@blessing.io 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
something else might be more appropriate. Something to think about.
On Thu, Jun 18, 2015 at 12:48 PM Douglas Garstang <
doug.garstang@gmail.com> 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--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
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 dey.ranjib@gmail.com 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
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 <
doug.garstang@gmail.com> 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
yeah exactly. i dont follow those pattern, in fact i cant recall reading
many of them, after sometime there were too many i could not connect the
dots. I try to use the original chef style.,. which is single repo for the
org, with berks integration so that we can churn out community cookbooks
(both ways, consume and publish), as well as if any service /app team wants
to take over their cookbooks, they are more than welcome. roles are more
like aggregation units, that assemble community/core stuff along with
service ..and attribute driven customization mostly uses default
precedence, if they are service specific, they go to roles (like nginx
connection limit, db memory settings), if the customizations are global
(like dns, ldap) they go to environment. some of these cross environments
settings are common hence the yaml trick, else we would have something like
base env. But till now i never felt like we'll need deeper nesting (not
sure if its good as well),, general topology of chef domain objects
(cookbook, role, environments) is similar to standard OOP strategy.. have
no more than 3 (shallow ) nesting (roles, envs).. with lot of mixins
(cookbooks). Some of the top level mixins (wrapper or applications
cookbooks) needs to be bit more intelligent hold more logic,, they
distribute that logic between hwrps,lwrps, modules, gems etc.
hth
On Thu, Jun 18, 2015 at 1:34 PM, Douglas Garstang doug.garstang@gmail.com
wrote:
Yoshi,
So, you basically have a role called common-env (or whatever), set common
attributes there, and then include the common-env in your run list as well
as the functional (ie web-server, apache-server etc) role?Douglas.
On Thu, Jun 18, 2015 at 12:52 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:Roles and Environments have two attribute levels available, default and
override, so you can do overrides either way.In the setup here we use common or default attributes in a role cookbook
and then set any environment specific overrides in an environment. That way
there are no duplicated values in environments.On Thu, Jun 18, 2015 at 11:24 AM, Douglas Garstang <
doug.garstang@gmail.com> wrote: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.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.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.Doug.
On Thu, Jun 18, 2015 at 11:04 AM, Drew Blessing drew@blessing.io
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
something else might be more appropriate. Something to think about.
On Thu, Jun 18, 2015 at 12:48 PM Douglas Garstang <
doug.garstang@gmail.com> 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--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
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 dey.ranjib@gmail.com 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 dey.ranjib@gmail.com 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
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 <
doug.garstang@gmail.com> 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
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
I have a role cookbook and a base cookbook. My nodes only ever have one
recipe from the role cookbook and the default recipe from the base
cookbook. These two recipes do everything I need to configure my nodes,
including calling any base cookbooks (in which case default attributes are
overridden in the role) and wrapper cookbooks (attributes overridden in the
wrapper if they're defaults for the company).
Anything that is unique to the company goes in this role cookbook and
anything that is unique to an environment goes in the environment. Because
I'm using cookbook default attributes they're easy to override anywhere.
Some people (in fact Chef recommend) taking this a step further and having
a cookbook per role instead of a role cookbook with a recipe per role.
On Thu, Jun 18, 2015 at 1:44 PM, Ranjib Dey dey.ranjib@gmail.com wrote:
yeah exactly. i dont follow those pattern, in fact i cant recall reading
many of them, after sometime there were too many i could not connect the
dots. I try to use the original chef style.,. which is single repo for the
org, with berks integration so that we can churn out community cookbooks
(both ways, consume and publish), as well as if any service /app team wants
to take over their cookbooks, they are more than welcome. roles are more
like aggregation units, that assemble community/core stuff along with
service ..and attribute driven customization mostly uses default
precedence, if they are service specific, they go to roles (like nginx
connection limit, db memory settings), if the customizations are global
(like dns, ldap) they go to environment. some of these cross environments
settings are common hence the yaml trick, else we would have something like
base env. But till now i never felt like we'll need deeper nesting (not
sure if its good as well),, general topology of chef domain objects
(cookbook, role, environments) is similar to standard OOP strategy.. have
no more than 3 (shallow ) nesting (roles, envs).. with lot of mixins
(cookbooks). Some of the top level mixins (wrapper or applications
cookbooks) needs to be bit more intelligent hold more logic,, they
distribute that logic between hwrps,lwrps, modules, gems etc.
hthOn Thu, Jun 18, 2015 at 1:34 PM, Douglas Garstang <doug.garstang@gmail.com
wrote:
Yoshi,
So, you basically have a role called common-env (or whatever), set common
attributes there, and then include the common-env in your run list as well
as the functional (ie web-server, apache-server etc) role?Douglas.
On Thu, Jun 18, 2015 at 12:52 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:Roles and Environments have two attribute levels available, default and
override, so you can do overrides either way.In the setup here we use common or default attributes in a role cookbook
and then set any environment specific overrides in an environment. That way
there are no duplicated values in environments.On Thu, Jun 18, 2015 at 11:24 AM, Douglas Garstang <
doug.garstang@gmail.com> wrote: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.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.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.Doug.
On Thu, Jun 18, 2015 at 11:04 AM, Drew Blessing drew@blessing.io
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
something else might be more appropriate. Something to think about.
On Thu, Jun 18, 2015 at 12:48 PM Douglas Garstang <
doug.garstang@gmail.com> 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--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com
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 doug.garstang@gmail.com
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 dey.ranjib@gmail.com 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 dey.ranjib@gmail.com 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
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 <
doug.garstang@gmail.com> 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--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627
--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com
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 <
yoshi.spendiff@indochino.com> 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 <doug.garstang@gmail.com
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 dey.ranjib@gmail.com 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 dey.ranjib@gmail.com
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
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 <
doug.garstang@gmail.com> 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--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com
--
Galen Emery
Hey Ranjib,
mind sharing an example snippet on how you do that?
Thought that includes were not possible with json environment files, but
yes, indeed they can be ruby dsl as well...
Cheers, Torben
Am 18.06.2015 22:30 schrieb "Ranjib Dey" dey.ranjib@gmail.com:
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
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 <
doug.garstang@gmail.com> 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
sure:
On Thu, Jun 18, 2015 at 3:05 PM, Torben Knerr mail@tknerr.de wrote:
Hey Ranjib,
mind sharing an example snippet on how you do that?
Thought that includes were not possible with json environment files, but
yes, indeed they can be ruby dsl as well...Cheers, Torben
Am 18.06.2015 22:30 schrieb "Ranjib Dey" dey.ranjib@gmail.com: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
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 <
doug.garstang@gmail.com> 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
Awesome, thanks Ranjib!
Am 19.06.2015 00:16 schrieb "Ranjib Dey" dey.ranjib@gmail.com:
sure:
Consuming common datra across environments using Chef's ruby environment DSL · GitHub
On Thu, Jun 18, 2015 at 3:05 PM, Torben Knerr mail@tknerr.de wrote:
Hey Ranjib,
mind sharing an example snippet on how you do that?
Thought that includes were not possible with json environment files, but
yes, indeed they can be ruby dsl as well...Cheers, Torben
Am 18.06.2015 22:30 schrieb "Ranjib Dey" dey.ranjib@gmail.com: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
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 <
doug.garstang@gmail.com> 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
Doug,
You may know this but since its been suggested to play around with precedence levels for attributes. Might be worth mentioning that array attributes are always union merged. I tend to stick with hashes whenever possible in my cookbooks because of this behaviour. But if your heavily using community cookbooks you might run into this.
I bookmarked this post to help explain it to others in my organization as it seems to always confuse a lot of people new to chef.
Arrays and Chef Attributes – Noah Kantrowitz
Regards,Phil
From: Torben KnerrSent: Thursday, June 18, 2015 6:05 PMTo: chef@lists.opscode.comReply To: chef@lists.opscode.comSubject: [chef] Re: Re: Environment Inheritence
Hey Ranjib,
mind sharing an example snippet on how you do that?
Thought that includes were not possible with json environment files, but yes, indeed they can be ruby dsl as well...
Cheers, Torben
Am 18.06.2015 22:30 schrieb "Ranjib Dey" <dey.ranjib@gmail.com>:
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 <doug.garstang@gmail.com> 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
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 galen@getchef.com 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 <
yoshi.spendiff@indochino.com> 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 <
doug.garstang@gmail.com> 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 dey.ranjib@gmail.com
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 dey.ranjib@gmail.com
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
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 <
doug.garstang@gmail.com> 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--
Regards,Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com--
Galen Emery
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627