Attribute Names


#1

I’m mostly curious how others handle this.

We have a chef environment where attribute can be located in three
places;the cookbook attributes, environments and roles (and in some cases,
in other cookbooks.)

Having to figure out where an attribute is set is occasionally frustrating
when I have to search in several places.

An idea proposed was the have the taxonomy of the attribute define where
it is being set.

Example:
[‘example’][‘attr’][‘value’] if set in the cookbook’s attributes.
[‘example’][‘env’][‘value’] if set in the environments.
[‘example’][‘node’][‘value’] if set in the node.

I understand this breaks the precedence structure of attributes as we now
having unique attribute names based on location.

But having to find where the attribute is set can be a bit tedious.

I’m curious how others handle this. What method do you use so that looking
at an attribute in a cookbook, they know where to go find it rather than
search for it.


Matthew Sims


#2

On Wednesday, March 20, 2013 at 4:56 PM, Matthew Sims wrote:

I’m mostly curious how others handle this.

We have a chef environment where attribute can be located in three
places;the cookbook attributes, environments and roles (and in some cases,
in other cookbooks.)

Having to figure out where an attribute is set is occasionally frustrating
when I have to search in several places.

An idea proposed was the have the taxonomy of the attribute define where
it is being set.

Example:
[‘example’][‘attr’][‘value’] if set in the cookbook’s attributes.
[‘example’][‘env’][‘value’] if set in the environments.
[‘example’][‘node’][‘value’] if set in the node.

I understand this breaks the precedence structure of attributes as we now
having unique attribute names based on location.

But having to find where the attribute is set can be a bit tedious.

I’m curious how others handle this. What method do you use so that looking
at an attribute in a cookbook, they know where to go find it rather than
search for it.


Matthew Sims

At the last minute before shipping Chef 11, I added some debugging code I was using to chef core. It’s only useful during a chef run, but hopefully you find it helpful.

Synopsis:

Recipe:

require 'pp’
pp node.debug_value(:test, :source)

Output:

[[“set_unless_enabled?”, false],
[“default”, “attributes default”],
[“env_default”, :not_present],
[“role_default”, “role default”],
[“force_default”, :not_present],
[“normal”, “attributes normal”],
[“override”, “attributes override”],
[“role_override”, “role override”],
[“env_override”, :not_present],
[“force_override”, :not_present],
[“automatic”, :not_present]]

More info:

Read http://www.opscode.com/blog/2013/02/05/chef-11-in-depth-attributes-changes/ and scroll to the “debugging attributes” section.

HTH,


Daniel DeLeo


#3

On Wednesday, March 20, 2013 at 4:56 PM, Matthew Sims wrote:

I’m mostly curious how others handle this.

We have a chef environment where attribute can be located in three
places;the cookbook attributes, environments and roles (and in some
cases,
in other cookbooks.)

Having to figure out where an attribute is set is occasionally
frustrating
when I have to search in several places.

An idea proposed was the have the taxonomy of the attribute define where
it is being set.

Example:
[‘example’][‘attr’][‘value’] if set in the cookbook’s attributes.
[‘example’][‘env’][‘value’] if set in the environments.
[‘example’][‘node’][‘value’] if set in the node.

I understand this breaks the precedence structure of attributes as we
now
having unique attribute names based on location.

But having to find where the attribute is set can be a bit tedious.

I’m curious how others handle this. What method do you use so that
looking
at an attribute in a cookbook, they know where to go find it rather than
search for it.


Matthew Sims

At the last minute before shipping Chef 11, I added some debugging code I
was using to chef core. It’s only useful during a chef run, but hopefully
you find it helpful.

Synopsis:

Recipe:

require 'pp’
pp node.debug_value(:test, :source)

Output:

[[“set_unless_enabled?”, false],
[“default”, “attributes default”],
[“env_default”, :not_present],
[“role_default”, “role default”],
[“force_default”, :not_present],
[“normal”, “attributes normal”],
[“override”, “attributes override”],
[“role_override”, “role override”],
[“env_override”, :not_present],
[“force_override”, :not_present],
[“automatic”, :not_present]]

More info:

Read
http://www.opscode.com/blog/2013/02/05/chef-11-in-depth-attributes-changes/
and scroll to the “debugging attributes” section.

HTH,


Daniel DeLeo

Debugging Attributes, nice. That will be incredibly helpful. Thank you. :slight_smile:


Matthew Sims


#4

Hi,

On Thu, Mar 21, 2013 at 10:56 AM, Matthew Sims matt@simsweb.org wrote:

I’m mostly curious how others handle this.

We have a chef environment where attribute can be located in three
places;the cookbook attributes, environments and roles (and in some cases,
in other cookbooks.)

To avoid this complexity we have taken a somewhat simple approach.

We practically never use normal priority attributes. Occasionally we
may associate a node with a issue in issue tracker, or a point of
contact etc. In which case we use normal attributes either through the
GUI or CLI but never in cookbooks/roles/env files.

Our “reusable” cookbooks [1],[2] set attributes in attribute files at
the default priority if users can override them and at "override"
priority if they are simply being published for consumption by other
cookbooks. Our role and/or wrapper [3] cookbooks set override priority
attributes in a recipe. Our roles almost never set any attributes and
if they do they will never bet set anywhere other than other roles and
they are override priority. (They are typically flags that are read by
a role cookbook to switch between behaviours). Our environments rarely
set any attributes and if they do they will never be set anywhere
other than other environments and they are override priority. (they
are also flag attributes)

HTH

[1] http://realityforge.org/code/2012/05/12/evolving-towards-cookbook-reusability-in-chef.html
[2] http://realityforge.org/code/2012/11/12/reusable-cookbooks-revisited.html
[3] http://realityforge.org/code/2012/11/19/role-cookbooks-and-wrapper-cookbooks.html


Cheers,

Peter Donald


#5

Hi,

On Thu, Mar 21, 2013 at 10:56 AM, Matthew Sims matt@simsweb.org wrote:

I’m mostly curious how others handle this.

We have a chef environment where attribute can be located in three
places;the cookbook attributes, environments and roles (and in some
cases,
in other cookbooks.)

To avoid this complexity we have taken a somewhat simple approach.

We practically never use normal priority attributes. Occasionally we
may associate a node with a issue in issue tracker, or a point of
contact etc. In which case we use normal attributes either through the
GUI or CLI but never in cookbooks/roles/env files.

Our “reusable” cookbooks [1],[2] set attributes in attribute files at
the default priority if users can override them and at "override"
priority if they are simply being published for consumption by other
cookbooks. Our role and/or wrapper [3] cookbooks set override priority
attributes in a recipe. Our roles almost never set any attributes and
if they do they will never bet set anywhere other than other roles and
they are override priority. (They are typically flags that are read by
a role cookbook to switch between behaviours). Our environments rarely
set any attributes and if they do they will never be set anywhere
other than other environments and they are override priority. (they
are also flag attributes)

HTH

[1]
http://realityforge.org/code/2012/05/12/evolving-towards-cookbook-reusability-in-chef.html
[2]
http://realityforge.org/code/2012/11/12/reusable-cookbooks-revisited.html
[3]
http://realityforge.org/code/2012/11/19/role-cookbooks-and-wrapper-cookbooks.html


Cheers,

Peter Donald

Thank you, Peter. Worth a read.


Matthew Sims