Environment Inheritence

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 doug.garstang@gmail.com
wrote:

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 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 :slight_smile: ) 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


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


Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

Wait wait! 1… 3…then 12!

On Thu, Jun 18, 2015 at 3:44 PM, Douglas Garstang doug.garstang@gmail.com
wrote:

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 <doug.garstang@gmail.com

wrote:

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 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 :slight_smile: ) 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


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


Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627


Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

If you do away with role attributes entirely and put them in role cookbooks
then you don’t have to use override on environments.

Alternatively you can set this on the nodes directly at force_override or
in the recipe itself at force_override if you really have to, although I
really would recommend designing your cookbooks in such a way that you
don’t have to much around with attribute priorities all over the place.

On Thu, Jun 18, 2015 at 3:44 PM, Douglas Garstang doug.garstang@gmail.com
wrote:

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 <doug.garstang@gmail.com

wrote:

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 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 :slight_smile: ) 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


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


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

Yoshi.

I can’t use force_override in a cookbook as I only want it on nodes
matching a certain function (across all environments).

Douglas.

On Thu, Jun 18, 2015 at 3:47 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

If you do away with role attributes entirely and put them in role
cookbooks then you don’t have to use override on environments.

Alternatively you can set this on the nodes directly at force_override or
in the recipe itself at force_override if you really have to, although I
really would recommend designing your cookbooks in such a way that you
don’t have to much around with attribute priorities all over the place.

On Thu, Jun 18, 2015 at 3:44 PM, Douglas Garstang <doug.garstang@gmail.com

wrote:

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 <
doug.garstang@gmail.com> wrote:

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 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 :slight_smile: ) 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


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


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.

Sometimes you gotta use roles. This particular attribute is only being set
on a specific class of machine. I can’t put it in an environment, and I
can’t put it in a cookbook either. It’s specifically designed to go on one
class of machine regardless of environment.

To be more specific, it’s OpenSSH’s ‘AcceptEnv’ setting. My bastion host
accepts AWS credentials via ssh. This only applies to the bastion host.

Doug.

On Thu, Jun 18, 2015 at 4:02 PM, Douglas Garstang doug.garstang@gmail.com
wrote:

Yoshi.

I can’t use force_override in a cookbook as I only want it on nodes
matching a certain function (across all environments).

Douglas.

On Thu, Jun 18, 2015 at 3:47 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

If you do away with role attributes entirely and put them in role
cookbooks then you don’t have to use override on environments.

Alternatively you can set this on the nodes directly at force_override or
in the recipe itself at force_override if you really have to, although I
really would recommend designing your cookbooks in such a way that you
don’t have to much around with attribute priorities all over the place.

On Thu, Jun 18, 2015 at 3:44 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

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 <
doug.garstang@gmail.com> wrote:

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 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 :slight_smile: ) 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


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


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


Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

Yes, but do those nodes run a particular recipe that others don’t? Because
you can put the override in your recipe, not your cookbook attributes.

Use node.force_override[‘my’][‘attribute’] in the recipe code.

Otherwise you can set a node attribute directly as force_override priority.

I feel like you’re getting into some sticky territory here that better
design can help with…

On Thu, Jun 18, 2015 at 4:02 PM, Douglas Garstang doug.garstang@gmail.com
wrote:

Yoshi.

I can’t use force_override in a cookbook as I only want it on nodes
matching a certain function (across all environments).

Douglas.

On Thu, Jun 18, 2015 at 3:47 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

If you do away with role attributes entirely and put them in role
cookbooks then you don’t have to use override on environments.

Alternatively you can set this on the nodes directly at force_override or
in the recipe itself at force_override if you really have to, although I
really would recommend designing your cookbooks in such a way that you
don’t have to much around with attribute priorities all over the place.

On Thu, Jun 18, 2015 at 3:44 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

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 <
doug.garstang@gmail.com> wrote:

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 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 :slight_smile: ) 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


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


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

If you use a recipe attribute then remember that a recipe is only run once
and it will use the attributes as specified when running. So if your recipe
hasn’t run yet to change the attribute when the other recipe that needs the
change runs your alteration won’t apply.

I’m sure there’s a way around this but I haven’t found it and would be
happy for someone to correct me.

On Thu, Jun 18, 2015 at 4:20 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

Yes, but do those nodes run a particular recipe that others don’t? Because
you can put the override in your recipe, not your cookbook attributes.

Use node.force_override[‘my’][‘attribute’] in the recipe code.

Otherwise you can set a node attribute directly as force_override priority.

I feel like you’re getting into some sticky territory here that better
design can help with…

On Thu, Jun 18, 2015 at 4:02 PM, Douglas Garstang <doug.garstang@gmail.com

wrote:

Yoshi.

I can’t use force_override in a cookbook as I only want it on nodes
matching a certain function (across all environments).

Douglas.

On Thu, Jun 18, 2015 at 3:47 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

If you do away with role attributes entirely and put them in role
cookbooks then you don’t have to use override on environments.

Alternatively you can set this on the nodes directly at force_override
or in the recipe itself at force_override if you really have to, although I
really would recommend designing your cookbooks in such a way that you
don’t have to much around with attribute priorities all over the place.

On Thu, Jun 18, 2015 at 3:44 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

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 <
doug.garstang@gmail.com> wrote:

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 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 :slight_smile: ) 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


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


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


Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com

Yoshi.

Your saying to override the attributes in a recipe… I don’t have a
cookbook for openssh. I’m using the community cookbook. To do what your
suggesting, I’d have to create a wrapper cookbook just for the purposes of
setting an attribute that’s only used on one class of machine. I don’t
think that’s a good idea.

Doug.

On Thu, Jun 18, 2015 at 4:20 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

Yes, but do those nodes run a particular recipe that others don’t? Because
you can put the override in your recipe, not your cookbook attributes.

Use node.force_override[‘my’][‘attribute’] in the recipe code.

Otherwise you can set a node attribute directly as force_override priority.

I feel like you’re getting into some sticky territory here that better
design can help with…

On Thu, Jun 18, 2015 at 4:02 PM, Douglas Garstang <doug.garstang@gmail.com

wrote:

Yoshi.

I can’t use force_override in a cookbook as I only want it on nodes
matching a certain function (across all environments).

Douglas.

On Thu, Jun 18, 2015 at 3:47 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

If you do away with role attributes entirely and put them in role
cookbooks then you don’t have to use override on environments.

Alternatively you can set this on the nodes directly at force_override
or in the recipe itself at force_override if you really have to, although I
really would recommend designing your cookbooks in such a way that you
don’t have to much around with attribute priorities all over the place.

On Thu, Jun 18, 2015 at 3:44 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

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 <
doug.garstang@gmail.com> wrote:

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 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 :slight_smile: ) 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


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


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


Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

You don’t necessarily have to make a wrapper cookbook to override one
attribute. Do it where it’s needed.

I do this in one of my recipes to enable ssh password authentication on one
type of node but have it disabled by default for all others:

node.override[‘sshd’][‘sshd_config’][‘PasswordAuthentication’] = 'yes’
include_recipe ‘sshd’

This is in my recipe that creates a user with a specific password. This
recipe is only run against nodes that need this user. Below this I have

user ‘myuser’ do
home '/foo/bar’
shell '/foo/bar’
end

And everything else the recipe does.

Making a wrapper cookbook only makes sense if multiple different types of
systems use the same attribute overrides every time, or if you want to add
further recipes to the base cookbook.

In your case you just want one type of server to do one very specific
thing, so just do it in the recipe that configures that type of node,
whether that’s in a role cookbook or anywhere else.

On Thu, Jun 18, 2015 at 4:23 PM, Douglas Garstang doug.garstang@gmail.com
wrote:

Yoshi.

Your saying to override the attributes in a recipe… I don’t have a
cookbook for openssh. I’m using the community cookbook. To do what your
suggesting, I’d have to create a wrapper cookbook just for the purposes of
setting an attribute that’s only used on one class of machine. I don’t
think that’s a good idea.

Doug.

On Thu, Jun 18, 2015 at 4:20 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

Yes, but do those nodes run a particular recipe that others don’t?
Because you can put the override in your recipe, not your cookbook
attributes.

Use node.force_override[‘my’][‘attribute’] in the recipe code.

Otherwise you can set a node attribute directly as force_override
priority.

I feel like you’re getting into some sticky territory here that better
design can help with…

On Thu, Jun 18, 2015 at 4:02 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

Yoshi.

I can’t use force_override in a cookbook as I only want it on nodes
matching a certain function (across all environments).

Douglas.

On Thu, Jun 18, 2015 at 3:47 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

If you do away with role attributes entirely and put them in role
cookbooks then you don’t have to use override on environments.

Alternatively you can set this on the nodes directly at force_override
or in the recipe itself at force_override if you really have to, although I
really would recommend designing your cookbooks in such a way that you
don’t have to much around with attribute priorities all over the place.

On Thu, Jun 18, 2015 at 3:44 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

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 <
doug.garstang@gmail.com> wrote:

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 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 :slight_smile: ) 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


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


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


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

As I was saying the only annoying part of this is that I have to include
this recipe before any others that contain *include_recipe ‘sshd’ *so that
my recipe override works, which I feel there must be a way around.

On Thu, Jun 18, 2015 at 4:30 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

You don’t necessarily have to make a wrapper cookbook to override one
attribute. Do it where it’s needed.

I do this in one of my recipes to enable ssh password authentication on
one type of node but have it disabled by default for all others:

node.override[‘sshd’][‘sshd_config’][‘PasswordAuthentication’] = 'yes’
include_recipe ‘sshd’

This is in my recipe that creates a user with a specific password. This
recipe is only run against nodes that need this user. Below this I have

user ‘myuser’ do
home '/foo/bar’
shell '/foo/bar’
end

And everything else the recipe does.

Making a wrapper cookbook only makes sense if multiple different types of
systems use the same attribute overrides every time, or if you want to add
further recipes to the base cookbook.

In your case you just want one type of server to do one very specific
thing, so just do it in the recipe that configures that type of node,
whether that’s in a role cookbook or anywhere else.

On Thu, Jun 18, 2015 at 4:23 PM, Douglas Garstang <doug.garstang@gmail.com

wrote:

Yoshi.

Your saying to override the attributes in a recipe… I don’t have a
cookbook for openssh. I’m using the community cookbook. To do what your
suggesting, I’d have to create a wrapper cookbook just for the purposes of
setting an attribute that’s only used on one class of machine. I don’t
think that’s a good idea.

Doug.

On Thu, Jun 18, 2015 at 4:20 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

Yes, but do those nodes run a particular recipe that others don’t?
Because you can put the override in your recipe, not your cookbook
attributes.

Use node.force_override[‘my’][‘attribute’] in the recipe code.

Otherwise you can set a node attribute directly as force_override
priority.

I feel like you’re getting into some sticky territory here that better
design can help with…

On Thu, Jun 18, 2015 at 4:02 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

Yoshi.

I can’t use force_override in a cookbook as I only want it on nodes
matching a certain function (across all environments).

Douglas.

On Thu, Jun 18, 2015 at 3:47 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

If you do away with role attributes entirely and put them in role
cookbooks then you don’t have to use override on environments.

Alternatively you can set this on the nodes directly at force_override
or in the recipe itself at force_override if you really have to, although I
really would recommend designing your cookbooks in such a way that you
don’t have to much around with attribute priorities all over the place.

On Thu, Jun 18, 2015 at 3:44 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

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 <
doug.garstang@gmail.com> wrote:

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 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 :slight_smile: ) 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


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


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


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


Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com

So… if I had one cookbook per environment, how on earth do cookbook
dependencies work? I can’t put them ALL into metadata.rb and Berksfile…

Doug.

On Thu, Jun 18, 2015 at 4:31 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

As I was saying the only annoying part of this is that I have to include
this recipe before any others that contain *include_recipe ‘sshd’ *so
that my recipe override works, which I feel there must be a way around.

On Thu, Jun 18, 2015 at 4:30 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

You don’t necessarily have to make a wrapper cookbook to override one
attribute. Do it where it’s needed.

I do this in one of my recipes to enable ssh password authentication on
one type of node but have it disabled by default for all others:

node.override[‘sshd’][‘sshd_config’][‘PasswordAuthentication’] = 'yes’
include_recipe ‘sshd’

This is in my recipe that creates a user with a specific password. This
recipe is only run against nodes that need this user. Below this I have

user ‘myuser’ do
home '/foo/bar’
shell '/foo/bar’
end

And everything else the recipe does.

Making a wrapper cookbook only makes sense if multiple different types of
systems use the same attribute overrides every time, or if you want to add
further recipes to the base cookbook.

In your case you just want one type of server to do one very specific
thing, so just do it in the recipe that configures that type of node,
whether that’s in a role cookbook or anywhere else.

On Thu, Jun 18, 2015 at 4:23 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

Yoshi.

Your saying to override the attributes in a recipe… I don’t have a
cookbook for openssh. I’m using the community cookbook. To do what your
suggesting, I’d have to create a wrapper cookbook just for the purposes of
setting an attribute that’s only used on one class of machine. I don’t
think that’s a good idea.

Doug.

On Thu, Jun 18, 2015 at 4:20 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

Yes, but do those nodes run a particular recipe that others don’t?
Because you can put the override in your recipe, not your cookbook
attributes.

Use node.force_override[‘my’][‘attribute’] in the recipe code.

Otherwise you can set a node attribute directly as force_override
priority.

I feel like you’re getting into some sticky territory here that better
design can help with…

On Thu, Jun 18, 2015 at 4:02 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

Yoshi.

I can’t use force_override in a cookbook as I only want it on nodes
matching a certain function (across all environments).

Douglas.

On Thu, Jun 18, 2015 at 3:47 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

If you do away with role attributes entirely and put them in role
cookbooks then you don’t have to use override on environments.

Alternatively you can set this on the nodes directly at
force_override or in the recipe itself at force_override if you really have
to, although I really would recommend designing your cookbooks in such a
way that you don’t have to much around with attribute priorities all over
the place.

On Thu, Jun 18, 2015 at 3:44 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

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 <
doug.garstang@gmail.com> wrote:

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 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 :slight_smile: ) 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


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


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


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


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

I realise that my top level run list would contain something like env-dev,
base, some_foo. I also realise that for individual cookbooks I’d have to
set attributes in my Vagrantfile, which I really don’t like because it then
means I’m not actually testing the same thing as what the env-dev cookbook
contains. However, it gets really bad when you want to test the base
cookbook. I’d have to replicate every attribute from every other cookbook
that’s included into the Vagrantfile. It also means that if I add a new
cookbook to the base role, I have to manually add it’s attributes each time
as well. This option does not scale.

Doug.

On Thu, Jun 18, 2015 at 4:48 PM, Douglas Garstang doug.garstang@gmail.com
wrote:

So… if I had one cookbook per environment, how on earth do cookbook
dependencies work? I can’t put them ALL into metadata.rb and Berksfile…

Doug.

On Thu, Jun 18, 2015 at 4:31 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

As I was saying the only annoying part of this is that I have to include
this recipe before any others that contain *include_recipe ‘sshd’ *so
that my recipe override works, which I feel there must be a way around.

On Thu, Jun 18, 2015 at 4:30 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

You don’t necessarily have to make a wrapper cookbook to override one
attribute. Do it where it’s needed.

I do this in one of my recipes to enable ssh password authentication on
one type of node but have it disabled by default for all others:

node.override[‘sshd’][‘sshd_config’][‘PasswordAuthentication’] = 'yes’
include_recipe ‘sshd’

This is in my recipe that creates a user with a specific password. This
recipe is only run against nodes that need this user. Below this I have

user ‘myuser’ do
home '/foo/bar’
shell '/foo/bar’
end

And everything else the recipe does.

Making a wrapper cookbook only makes sense if multiple different types
of systems use the same attribute overrides every time, or if you want to
add further recipes to the base cookbook.

In your case you just want one type of server to do one very specific
thing, so just do it in the recipe that configures that type of node,
whether that’s in a role cookbook or anywhere else.

On Thu, Jun 18, 2015 at 4:23 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

Yoshi.

Your saying to override the attributes in a recipe… I don’t have a
cookbook for openssh. I’m using the community cookbook. To do what your
suggesting, I’d have to create a wrapper cookbook just for the purposes of
setting an attribute that’s only used on one class of machine. I don’t
think that’s a good idea.

Doug.

On Thu, Jun 18, 2015 at 4:20 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

Yes, but do those nodes run a particular recipe that others don’t?
Because you can put the override in your recipe, not your cookbook
attributes.

Use node.force_override[‘my’][‘attribute’] in the recipe code.

Otherwise you can set a node attribute directly as force_override
priority.

I feel like you’re getting into some sticky territory here that better
design can help with…

On Thu, Jun 18, 2015 at 4:02 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

Yoshi.

I can’t use force_override in a cookbook as I only want it on nodes
matching a certain function (across all environments).

Douglas.

On Thu, Jun 18, 2015 at 3:47 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

If you do away with role attributes entirely and put them in role
cookbooks then you don’t have to use override on environments.

Alternatively you can set this on the nodes directly at
force_override or in the recipe itself at force_override if you really have
to, although I really would recommend designing your cookbooks in such a
way that you don’t have to much around with attribute priorities all over
the place.

On Thu, Jun 18, 2015 at 3:44 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

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 <
doug.garstang@gmail.com> wrote:

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 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 :slight_smile: ) 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


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


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


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


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


Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

That’s not what I mean at all.

When you construct your nodes you want to be consistent. If you want a
server of a specific function you should use the same run list for that
node in all cases, for every environment. You achieve this by either having
a role with this run_list or by assigning the run list directly to a node.

You use your environments to override any settings that are applied as
defaults to a role, or to give new settings that are specific to that
environment.

If you have a server type (role) which is only unique when that particular
role is in a particular environment then you need to either apply
attributes directly to the node or have your recipe be smart enough to work
out what environment it is in, if you have control of the recipe.

In the case where you have control of the recipe, either via a wrapper
cookbook or a cookbook in which you can control the recipes, then you would
do it something like this:

if node.chef_environment == ‘production’ node.force_override[‘thing’] =
‘foo’ Chef::Log.warn(‘production’)else node.force_override[‘thing’] =
‘bar’ Chef::Log.warn(‘not production’)endinclude_recipe ‘something’

This could be a recipe in your base cookbook that you only apply to the
role that thing change has meaning for, early in the run list.

Finally, if you are adding the openssh recipe as a part of the role run
list directly, not being called by *include_recipe ‘openssh::default’ *in
a recipe that you control, then your only option is to use node attributes
for those nodes, at the force_override priority if you are using override
in your environment. You will need to take care of adding the attributes to
the node when the node is created in chef. If you’re using knife to make
the instances then you can pass the -j flag and a json file containing
attributes, otherwise it depends on how the instances are created.

On Thu, Jun 18, 2015 at 5:03 PM, Douglas Garstang doug.garstang@gmail.com
wrote:

I realise that my top level run list would contain something like env-dev,
base, some_foo. I also realise that for individual cookbooks I’d have to
set attributes in my Vagrantfile, which I really don’t like because it then
means I’m not actually testing the same thing as what the env-dev cookbook
contains. However, it gets really bad when you want to test the base
cookbook. I’d have to replicate every attribute from every other cookbook
that’s included into the Vagrantfile. It also means that if I add a new
cookbook to the base role, I have to manually add it’s attributes each time
as well. This option does not scale.

Doug.

On Thu, Jun 18, 2015 at 4:48 PM, Douglas Garstang <doug.garstang@gmail.com

wrote:

So… if I had one cookbook per environment, how on earth do cookbook
dependencies work? I can’t put them ALL into metadata.rb and Berksfile…

Doug.

On Thu, Jun 18, 2015 at 4:31 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

As I was saying the only annoying part of this is that I have to include
this recipe before any others that contain *include_recipe ‘sshd’ *so
that my recipe override works, which I feel there must be a way around.

On Thu, Jun 18, 2015 at 4:30 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

You don’t necessarily have to make a wrapper cookbook to override one
attribute. Do it where it’s needed.

I do this in one of my recipes to enable ssh password authentication on
one type of node but have it disabled by default for all others:

node.override[‘sshd’][‘sshd_config’][‘PasswordAuthentication’] = 'yes’
include_recipe ‘sshd’

This is in my recipe that creates a user with a specific password. This
recipe is only run against nodes that need this user. Below this I have

user ‘myuser’ do
home '/foo/bar’
shell '/foo/bar’
end

And everything else the recipe does.

Making a wrapper cookbook only makes sense if multiple different types
of systems use the same attribute overrides every time, or if you want to
add further recipes to the base cookbook.

In your case you just want one type of server to do one very specific
thing, so just do it in the recipe that configures that type of node,
whether that’s in a role cookbook or anywhere else.

On Thu, Jun 18, 2015 at 4:23 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

Yoshi.

Your saying to override the attributes in a recipe… I don’t have a
cookbook for openssh. I’m using the community cookbook. To do what your
suggesting, I’d have to create a wrapper cookbook just for the purposes of
setting an attribute that’s only used on one class of machine. I don’t
think that’s a good idea.

Doug.

On Thu, Jun 18, 2015 at 4:20 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

Yes, but do those nodes run a particular recipe that others don’t?
Because you can put the override in your recipe, not your cookbook
attributes.

Use node.force_override[‘my’][‘attribute’] in the recipe code.

Otherwise you can set a node attribute directly as force_override
priority.

I feel like you’re getting into some sticky territory here that
better design can help with…

On Thu, Jun 18, 2015 at 4:02 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

Yoshi.

I can’t use force_override in a cookbook as I only want it on nodes
matching a certain function (across all environments).

Douglas.

On Thu, Jun 18, 2015 at 3:47 PM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

If you do away with role attributes entirely and put them in role
cookbooks then you don’t have to use override on environments.

Alternatively you can set this on the nodes directly at
force_override or in the recipe itself at force_override if you really have
to, although I really would recommend designing your cookbooks in such a
way that you don’t have to much around with attribute priorities all over
the place.

On Thu, Jun 18, 2015 at 3:44 PM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

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 <
doug.garstang@gmail.com> wrote:

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 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 :slight_smile: ) 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


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


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


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


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


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

On 06/18/2015 03:26 PM, Douglas Garstang wrote:

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. :~(

why are you going from recipe default directly to env_override (#12)
rather than env_default (#3)? if you notice env_default is designed to
be overridden by roles (“production is this way except for where i
decide to fiddle with things”) while env_override is designed to
override roles and nearly everything else (“production is this way
because I say so no exceptions, period”).

I can do that…

On Thu, Jun 18, 2015 at 10:10 PM, Lamont Granquist lamont@chef.io wrote:

On 06/18/2015 03:26 PM, Douglas Garstang wrote:

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. :~(

why are you going from recipe default directly to env_override (#12)
rather than env_default (#3)? if you notice env_default is designed to be
overridden by roles (“production is this way except for where i decide to
fiddle with things”) while env_override is designed to override roles and
nearly everything else (“production is this way because I say so no
exceptions, period”).


Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627

This might help you out Doug:

http://lists.opscode.com/sympa/arc/chef/2012-04/msg00325.html

On Fri, Jun 19, 2015 at 7:25 AM, Douglas Garstang doug.garstang@gmail.com
wrote:

I can do that…

On Thu, Jun 18, 2015 at 10:10 PM, Lamont Granquist lamont@chef.io wrote:

On 06/18/2015 03:26 PM, Douglas Garstang wrote:

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. :~(

why are you going from recipe default directly to env_override (#12)
rather than env_default (#3)? if you notice env_default is designed to be
overridden by roles (“production is this way except for where i decide to
fiddle with things”) while env_override is designed to override roles and
nearly everything else (“production is this way because I say so no
exceptions, period”).


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

Oops, should have been the third reply in that thread.

On Fri, Jun 19, 2015 at 11:31 AM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

This might help you out Doug:

http://lists.opscode.com/sympa/arc/chef/2012-04/msg00325.html

On Fri, Jun 19, 2015 at 7:25 AM, Douglas Garstang <doug.garstang@gmail.com

wrote:

I can do that…

On Thu, Jun 18, 2015 at 10:10 PM, Lamont Granquist lamont@chef.io
wrote:

On 06/18/2015 03:26 PM, Douglas Garstang wrote:

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. :~(

why are you going from recipe default directly to env_override (#12)
rather than env_default (#3)? if you notice env_default is designed to be
overridden by roles (“production is this way except for where i decide to
fiddle with things”) while env_override is designed to override roles and
nearly everything else (“production is this way because I say so no
exceptions, period”).


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


Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com

Yoshi.

Thanks. I’d like to respond with more, but quite honestly I’m afraid to.
Whatever I say will be misconstrued, so I will just end my participation in
this threa here. Thanks again for your help.

Douglas.

On Fri, Jun 19, 2015 at 11:32 AM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

Oops, should have been the third reply in that thread.

On Fri, Jun 19, 2015 at 11:31 AM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

This might help you out Doug:

http://lists.opscode.com/sympa/arc/chef/2012-04/msg00325.html

On Fri, Jun 19, 2015 at 7:25 AM, Douglas Garstang <
doug.garstang@gmail.com> wrote:

I can do that…

On Thu, Jun 18, 2015 at 10:10 PM, Lamont Granquist lamont@chef.io
wrote:

On 06/18/2015 03:26 PM, Douglas Garstang wrote:

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. :~(

why are you going from recipe default directly to env_override (#12)
rather than env_default (#3)? if you notice env_default is designed to be
overridden by roles (“production is this way except for where i decide to
fiddle with things”) while env_override is designed to override roles and
nearly everything else (“production is this way because I say so no
exceptions, period”).


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


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