Attributes constructed from other attributes aren't added to the attribute map


#1

Hi.

I just started using test-kitchen again after a bit of a break. I was surprised to find out that a very simple internal cookbook that we’ve been using now didn’t work.

The error occurred when evaluating our default attribute file. It was complaining about an attribute (attr3) that was composed with the value of another attribute (attr2), which in turn was composed from the value of another attribute (attr1). After adding some “raise” lines to the default.rb attribute file in our cookbook and a test recipe we were able to determine that attr1 was added to the map, while attr2 was not added and trying to construct attr3 then resulted in a failure.

Sorry for the convoluted explanation, I make some sad attempt to describe this here: https://gist.github.com/StFS/2a333afe352d0dc8cbb5

As I said I was using test-kitchen for this and in my .kitchen.yml file I had:
require_chef_omnibus: true

This installed Chef 12.0.3-1 on the vagrant machine (which is a CentOS 7). Since this had been working previously I dug around a bit and noticed that all of our earlier installations seemed to be using version 11 of Chef. So I changed my .kitchen.yml file to specify version 11 of chef and now at least I’m getting further and the attributes map seems to be built correctly in my recipe.

So my question is, is the following syntax for my attribute file in some way wrong? If so, what should I be using? If the syntax is not wrong, is this then a bug in Chef 12? Has it been reported (I didn’t find anything during my googling around for this problem)?

Here is an example of an attribute file that would fail:

default[‘chef_attribute_hell’][‘attr1’] = "attribute1"
default[‘chef_attribute_hell’][‘attr2’] = "#{node.chef_attribute_hell.attr1}/attr2"
default[‘chef_attribute_hell’][‘attr3’] = “#{node.chef_attribute_hell.attr2}/attr3”

Kind regards,
Stefan Freyr

p.s. I can make a full blown cookbook with a .kitchen.yml file available which demonstrates this problem if needed.


#2

The syntax is not wrong, this is unfortunately a very rare edge case
with the way that attribute reads are evaluated.

You can move any computed attributes to the Recipe’s Compile Phase in
order to Not Be Bitten By Things., e.g.:

node.default['chef_attribute_hell']['attr2'] = "#{...}/..."
node.default['chef_attribute_hell']['attr3'] =
"#{node.chef_attribute_hell.attr2}/attr3"

I wish the notes from the “Attributes WAT” community session had been
captured but it was a very high energy discussion – we went into the
details as to what causes this to occur. Something to do with the
"read time" of the attributes in the attributes DSL being before some
attribute precedence resolution happens, I fear, although I don’t
recall. HTH.

cheers,

–aj

On Tue, Dec 23, 2014 at 7:38 AM, Stefán Freyr Stefánsson
stefan@nextcode.com wrote:

Hi.

I just started using test-kitchen again after a bit of a break. I was
surprised to find out that a very simple internal cookbook that we’ve been
using now didn’t work.

The error occurred when evaluating our default attribute file. It was
complaining about an attribute (attr3) that was composed with the value of
another attribute (attr2), which in turn was composed from the value of
another attribute (attr1). After adding some “raise” lines to the default.rb
attribute file in our cookbook and a test recipe we were able to determine
that attr1 was added to the map, while attr2 was not added and trying to
construct attr3 then resulted in a failure.

Sorry for the convoluted explanation, I make some sad attempt to describe
this here: https://gist.github.com/StFS/2a333afe352d0dc8cbb5

As I said I was using test-kitchen for this and in my .kitchen.yml file I
had:
require_chef_omnibus: true

This installed Chef 12.0.3-1 on the vagrant machine (which is a CentOS 7).
Since this had been working previously I dug around a bit and noticed that
all of our earlier installations seemed to be using version 11 of Chef. So I
changed my .kitchen.yml file to specify version 11 of chef and now at least
I’m getting further and the attributes map seems to be built correctly in my
recipe.

So my question is, is the following syntax for my attribute file in some way
wrong? If so, what should I be using? If the syntax is not wrong, is this
then a bug in Chef 12? Has it been reported (I didn’t find anything during
my googling around for this problem)?

Here is an example of an attribute file that would fail:

default[‘chef_attribute_hell’][‘attr1’] = “attribute1"
default[‘chef_attribute_hell’][‘attr2’] =
”#{node.chef_attribute_hell.attr1}/attr2"
default[‘chef_attribute_hell’][‘attr3’] =
"#{node.chef_attribute_hell.attr2}/attr3"

Kind regards,
Stefan Freyr

p.s. I can make a full blown cookbook with a .kitchen.yml file available
which demonstrates this problem if needed.


#3

Hi.

Thanks for your answer. Unfortunately I’m not quite sure if I’m understanding it correctly, at least my understanding of the fix does not work.

What I did was I added ‘node.’ in front of my 'default[‘foo’][‘bar’] = …" in the attributes/default.rb file in my cookbook. Here are the full contents of the file as they stand after the change:

node.default[‘chef_attribute_hell’][‘attr1’] = "attribute1"
node.default[‘chef_attribute_hell’][‘attr2’] = "#{node.chef_attribute_hell.attr1}/attr2"
node.default[‘chef_attribute_hell’][‘attr3’] = “#{node.chef_attribute_hell.attr2}/attr3”

This still results in:

   NoMethodError
   -------------
   Undefined method or attribute `attr2' on `node'
   
   Cookbook Trace:
   ---------------
     /tmp/kitchen/cookbooks/chef_attribute_hell/attributes/default.rb:3:in `from_file'
   
   Relevant File Content:
   ----------------------
   /tmp/kitchen/cookbooks/chef_attribute_hell/attributes/default.rb:
   
     1:  node.default['chef_attribute_hell']['attr1'] = "attribute1"
     2:  node.default['chef_attribute_hell']['attr2'] = "#{node.chef_attribute_hell.attr1}/attr2"
     3>> node.default['chef_attribute_hell']['attr3'] = "#{node.chef_attribute_hell.attr2}/attr3"
     4:  

Finally, you say that this is a “very rare edge case”. All I did was make a cookbook with attributes that are constructed from values of previous attributes. Is that really an edge case? Is there some other way to accomplish the same thing? Because this seems like a bit of a fundamental thing to me.

Kind regards, Stefan Freyr.


From: AJ Christensen aj@junglistheavy.industries
Sent: Monday, December 22, 2014 7:19 PM
To: chef@lists.opscode.com
Subject: [chef] Re: attributes constructed from other attributes aren’t added to the attribute map

The syntax is not wrong, this is unfortunately a very rare edge case
with the way that attribute reads are evaluated.

You can move any computed attributes to the Recipe’s Compile Phase in
order to Not Be Bitten By Things., e.g.:

node.default['chef_attribute_hell']['attr2'] = "#{...}/..."
node.default['chef_attribute_hell']['attr3'] =
"#{node.chef_attribute_hell.attr2}/attr3"

I wish the notes from the “Attributes WAT” community session had been
captured but it was a very high energy discussion – we went into the
details as to what causes this to occur. Something to do with the
"read time" of the attributes in the attributes DSL being before some
attribute precedence resolution happens, I fear, although I don’t
recall. HTH.

cheers,

–aj

On Tue, Dec 23, 2014 at 7:38 AM, Stefán Freyr Stefánsson
stefan@nextcode.com wrote:

Hi.

I just started using test-kitchen again after a bit of a break. I was
surprised to find out that a very simple internal cookbook that we’ve been
using now didn’t work.

The error occurred when evaluating our default attribute file. It was
complaining about an attribute (attr3) that was composed with the value of
another attribute (attr2), which in turn was composed from the value of
another attribute (attr1). After adding some “raise” lines to the default.rb
attribute file in our cookbook and a test recipe we were able to determine
that attr1 was added to the map, while attr2 was not added and trying to
construct attr3 then resulted in a failure.

Sorry for the convoluted explanation, I make some sad attempt to describe
this here: https://gist.github.com/StFS/2a333afe352d0dc8cbb5

As I said I was using test-kitchen for this and in my .kitchen.yml file I
had:
require_chef_omnibus: true

This installed Chef 12.0.3-1 on the vagrant machine (which is a CentOS 7).
Since this had been working previously I dug around a bit and noticed that
all of our earlier installations seemed to be using version 11 of Chef. So I
changed my .kitchen.yml file to specify version 11 of chef and now at least
I’m getting further and the attributes map seems to be built correctly in my
recipe.

So my question is, is the following syntax for my attribute file in some way
wrong? If so, what should I be using? If the syntax is not wrong, is this
then a bug in Chef 12? Has it been reported (I didn’t find anything during
my googling around for this problem)?

Here is an example of an attribute file that would fail:

default[‘chef_attribute_hell’][‘attr1’] = “attribute1"
default[‘chef_attribute_hell’][‘attr2’] =
”#{node.chef_attribute_hell.attr1}/attr2"
default[‘chef_attribute_hell’][‘attr3’] =
"#{node.chef_attribute_hell.attr2}/attr3"

Kind regards,
Stefan Freyr

p.s. I can make a full blown cookbook with a .kitchen.yml file available
which demonstrates this problem if needed.


#4

Well… for future reference I’m replying to myself with a solution that seems to work.

We knew that composed attributes were being used in other “official” cookbooks (such as the main apache cookbook) so I dug into that to see how things were done there. The only thing I noticed was that they used a slightly different syntax.

So instead of:

default[‘chef_attribute_hell’][‘attr1’] = "attribute1"
default[‘chef_attribute_hell’][‘attr2’] = "#{node.chef_attribute_hell.attr1}/attr2"
default[‘chef_attribute_hell’][‘attr3’] = “#{node.chef_attribute_hell.attr2}/attr3”

They were doing it like this:

default[‘chef_attribute_hell’][‘attr1’] = "attribute1"
default[‘chef_attribute_hell’][‘attr2’] = "#{node[‘chef_attribute_hell’][‘attr1’]}/attr2"
default[‘chef_attribute_hell’][‘attr3’] = “#{node[‘chef_attribute_hell’][‘attr2’]}/attr3”

I tried that in my cookbook and voila… now everything seems to work.

Still not quite sure how the different syntaxes affect the compile time of the node attribute map but hey, at least now it works.

Kind regards and merry Christmas,
Stefan Freyr.


From: Stefán Freyr Stefánsson
Sent: Tuesday, December 23, 2014 11:00 AM
To: chef@lists.opscode.com
Subject: Re: [chef] Re: attributes constructed from other attributes aren’t added to the attribute map

Hi.

Thanks for your answer. Unfortunately I’m not quite sure if I’m understanding it correctly, at least my understanding of the fix does not work.

What I did was I added ‘node.’ in front of my 'default[‘foo’][‘bar’] = …" in the attributes/default.rb file in my cookbook. Here are the full contents of the file as they stand after the change:

node.default[‘chef_attribute_hell’][‘attr1’] = "attribute1"
node.default[‘chef_attribute_hell’][‘attr2’] = "#{node.chef_attribute_hell.attr1}/attr2"
node.default[‘chef_attribute_hell’][‘attr3’] = “#{node.chef_attribute_hell.attr2}/attr3”

This still results in:

   NoMethodError
   -------------
   Undefined method or attribute `attr2' on `node'

   Cookbook Trace:
   ---------------
     /tmp/kitchen/cookbooks/chef_attribute_hell/attributes/default.rb:3:in `from_file'

   Relevant File Content:
   ----------------------
   /tmp/kitchen/cookbooks/chef_attribute_hell/attributes/default.rb:

     1:  node.default['chef_attribute_hell']['attr1'] = "attribute1"
     2:  node.default['chef_attribute_hell']['attr2'] = "#{node.chef_attribute_hell.attr1}/attr2"
     3>> node.default['chef_attribute_hell']['attr3'] = "#{node.chef_attribute_hell.attr2}/attr3"
     4:

Finally, you say that this is a “very rare edge case”. All I did was make a cookbook with attributes that are constructed from values of previous attributes. Is that really an edge case? Is there some other way to accomplish the same thing? Because this seems like a bit of a fundamental thing to me.

Kind regards, Stefan Freyr.


From: AJ Christensen aj@junglistheavy.industries
Sent: Monday, December 22, 2014 7:19 PM
To: chef@lists.opscode.com
Subject: [chef] Re: attributes constructed from other attributes aren’t added to the attribute map

The syntax is not wrong, this is unfortunately a very rare edge case
with the way that attribute reads are evaluated.

You can move any computed attributes to the Recipe’s Compile Phase in
order to Not Be Bitten By Things., e.g.:

node.default['chef_attribute_hell']['attr2'] = "#{...}/..."
node.default['chef_attribute_hell']['attr3'] =
"#{node.chef_attribute_hell.attr2}/attr3"

I wish the notes from the “Attributes WAT” community session had been
captured but it was a very high energy discussion – we went into the
details as to what causes this to occur. Something to do with the
"read time" of the attributes in the attributes DSL being before some
attribute precedence resolution happens, I fear, although I don’t
recall. HTH.

cheers,

–aj

On Tue, Dec 23, 2014 at 7:38 AM, Stefán Freyr Stefánsson
stefan@nextcode.com wrote:

Hi.

I just started using test-kitchen again after a bit of a break. I was
surprised to find out that a very simple internal cookbook that we’ve been
using now didn’t work.

The error occurred when evaluating our default attribute file. It was
complaining about an attribute (attr3) that was composed with the value of
another attribute (attr2), which in turn was composed from the value of
another attribute (attr1). After adding some “raise” lines to the default.rb
attribute file in our cookbook and a test recipe we were able to determine
that attr1 was added to the map, while attr2 was not added and trying to
construct attr3 then resulted in a failure.

Sorry for the convoluted explanation, I make some sad attempt to describe
this here: https://gist.github.com/StFS/2a333afe352d0dc8cbb5

As I said I was using test-kitchen for this and in my .kitchen.yml file I
had:
require_chef_omnibus: true

This installed Chef 12.0.3-1 on the vagrant machine (which is a CentOS 7).
Since this had been working previously I dug around a bit and noticed that
all of our earlier installations seemed to be using version 11 of Chef. So I
changed my .kitchen.yml file to specify version 11 of chef and now at least
I’m getting further and the attributes map seems to be built correctly in my
recipe.

So my question is, is the following syntax for my attribute file in some way
wrong? If so, what should I be using? If the syntax is not wrong, is this
then a bug in Chef 12? Has it been reported (I didn’t find anything during
my googling around for this problem)?

Here is an example of an attribute file that would fail:

default[‘chef_attribute_hell’][‘attr1’] = “attribute1"
default[‘chef_attribute_hell’][‘attr2’] =
”#{node.chef_attribute_hell.attr1}/attr2"
default[‘chef_attribute_hell’][‘attr3’] =
"#{node.chef_attribute_hell.attr2}/attr3"

Kind regards,
Stefan Freyr

p.s. I can make a full blown cookbook with a .kitchen.yml file available
which demonstrates this problem if needed.


#5

A colleague of mine believes that the fact that one syntax works and the other one doesn’t probably means that this is not a case of attribute evaluation quirkiness and instead more likely a regression bug.

In any case I’ve filed a bug (https://github.com/opscode/chef/issues/2700). We’ll see what they say about it.

-Stefan Freyr.


From: Stefán Freyr Stefánsson
Sent: Tuesday, December 23, 2014 2:46 PM
To: chef@lists.opscode.com
Subject: Re: [chef] Re: attributes constructed from other attributes aren’t added to the attribute map

Well… for future reference I’m replying to myself with a solution that seems to work.

We knew that composed attributes were being used in other “official” cookbooks (such as the main apache cookbook) so I dug into that to see how things were done there. The only thing I noticed was that they used a slightly different syntax.

So instead of:

default[‘chef_attribute_hell’][‘attr1’] = "attribute1"
default[‘chef_attribute_hell’][‘attr2’] = "#{node.chef_attribute_hell.attr1}/attr2"
default[‘chef_attribute_hell’][‘attr3’] = “#{node.chef_attribute_hell.attr2}/attr3”

They were doing it like this:

default[‘chef_attribute_hell’][‘attr1’] = "attribute1"
default[‘chef_attribute_hell’][‘attr2’] = "#{node[‘chef_attribute_hell’][‘attr1’]}/attr2"
default[‘chef_attribute_hell’][‘attr3’] = “#{node[‘chef_attribute_hell’][‘attr2’]}/attr3”

I tried that in my cookbook and voila… now everything seems to work.

Still not quite sure how the different syntaxes affect the compile time of the node attribute map but hey, at least now it works.

Kind regards and merry Christmas,
Stefan Freyr.


From: Stefán Freyr Stefánsson
Sent: Tuesday, December 23, 2014 11:00 AM
To: chef@lists.opscode.com
Subject: Re: [chef] Re: attributes constructed from other attributes aren’t added to the attribute map

Hi.

Thanks for your answer. Unfortunately I’m not quite sure if I’m understanding it correctly, at least my understanding of the fix does not work.

What I did was I added ‘node.’ in front of my 'default[‘foo’][‘bar’] = …" in the attributes/default.rb file in my cookbook. Here are the full contents of the file as they stand after the change:

node.default[‘chef_attribute_hell’][‘attr1’] = "attribute1"
node.default[‘chef_attribute_hell’][‘attr2’] = "#{node.chef_attribute_hell.attr1}/attr2"
node.default[‘chef_attribute_hell’][‘attr3’] = “#{node.chef_attribute_hell.attr2}/attr3”

This still results in:

   NoMethodError
   -------------
   Undefined method or attribute `attr2' on `node'

   Cookbook Trace:
   ---------------
     /tmp/kitchen/cookbooks/chef_attribute_hell/attributes/default.rb:3:in `from_file'

   Relevant File Content:
   ----------------------
   /tmp/kitchen/cookbooks/chef_attribute_hell/attributes/default.rb:

     1:  node.default['chef_attribute_hell']['attr1'] = "attribute1"
     2:  node.default['chef_attribute_hell']['attr2'] = "#{node.chef_attribute_hell.attr1}/attr2"
     3>> node.default['chef_attribute_hell']['attr3'] = "#{node.chef_attribute_hell.attr2}/attr3"
     4:

Finally, you say that this is a “very rare edge case”. All I did was make a cookbook with attributes that are constructed from values of previous attributes. Is that really an edge case? Is there some other way to accomplish the same thing? Because this seems like a bit of a fundamental thing to me.

Kind regards, Stefan Freyr.


From: AJ Christensen aj@junglistheavy.industries
Sent: Monday, December 22, 2014 7:19 PM
To: chef@lists.opscode.com
Subject: [chef] Re: attributes constructed from other attributes aren’t added to the attribute map

The syntax is not wrong, this is unfortunately a very rare edge case
with the way that attribute reads are evaluated.

You can move any computed attributes to the Recipe’s Compile Phase in
order to Not Be Bitten By Things., e.g.:

node.default['chef_attribute_hell']['attr2'] = "#{...}/..."
node.default['chef_attribute_hell']['attr3'] =
"#{node.chef_attribute_hell.attr2}/attr3"

I wish the notes from the “Attributes WAT” community session had been
captured but it was a very high energy discussion – we went into the
details as to what causes this to occur. Something to do with the
"read time" of the attributes in the attributes DSL being before some
attribute precedence resolution happens, I fear, although I don’t
recall. HTH.

cheers,

–aj

On Tue, Dec 23, 2014 at 7:38 AM, Stefán Freyr Stefánsson
stefan@nextcode.com wrote:

Hi.

I just started using test-kitchen again after a bit of a break. I was
surprised to find out that a very simple internal cookbook that we’ve been
using now didn’t work.

The error occurred when evaluating our default attribute file. It was
complaining about an attribute (attr3) that was composed with the value of
another attribute (attr2), which in turn was composed from the value of
another attribute (attr1). After adding some “raise” lines to the default.rb
attribute file in our cookbook and a test recipe we were able to determine
that attr1 was added to the map, while attr2 was not added and trying to
construct attr3 then resulted in a failure.

Sorry for the convoluted explanation, I make some sad attempt to describe
this here: https://gist.github.com/StFS/2a333afe352d0dc8cbb5

As I said I was using test-kitchen for this and in my .kitchen.yml file I
had:
require_chef_omnibus: true

This installed Chef 12.0.3-1 on the vagrant machine (which is a CentOS 7).
Since this had been working previously I dug around a bit and noticed that
all of our earlier installations seemed to be using version 11 of Chef. So I
changed my .kitchen.yml file to specify version 11 of chef and now at least
I’m getting further and the attributes map seems to be built correctly in my
recipe.

So my question is, is the following syntax for my attribute file in some way
wrong? If so, what should I be using? If the syntax is not wrong, is this
then a bug in Chef 12? Has it been reported (I didn’t find anything during
my googling around for this problem)?

Here is an example of an attribute file that would fail:

default[‘chef_attribute_hell’][‘attr1’] = “attribute1"
default[‘chef_attribute_hell’][‘attr2’] =
”#{node.chef_attribute_hell.attr1}/attr2"
default[‘chef_attribute_hell’][‘attr3’] =
"#{node.chef_attribute_hell.attr2}/attr3"

Kind regards,
Stefan Freyr

p.s. I can make a full blown cookbook with a .kitchen.yml file available
which demonstrates this problem if needed.


#6

I have a feeling i hit this yesterday with period-delimited (method
missing) chaines attributes syntax. Regression in 12.x? What versions you
running?

Per my original email, the node.default calls should happen in a recipe
compile time (not attributes) when calculating derived values (e.g.
interping other attributes)

Hth,

–aj
On Dec 24, 2014 4:57 AM, “Stefán Freyr Stefánsson” stefan@nextcode.com
wrote:

A colleague of mine believes that the fact that one syntax works and the
other one doesn’t probably means that this is not a case of attribute
evaluation quirkiness and instead more likely a regression bug.

In any case I’ve filed a bug (https://github.com/opscode/chef/issues/2700).
We’ll see what they say about it.

-Stefan Freyr.


From: Stefán Freyr Stefánsson
Sent: Tuesday, December 23, 2014 2:46 PM
To: chef@lists.opscode.com
Subject: Re: [chef] Re: attributes constructed from other attributes
aren’t added to the attribute map

Well… for future reference I’m replying to myself with a solution that
seems to work.

We knew that composed attributes were being used in other "official"
cookbooks (such as the main apache cookbook) so I dug into that to see how
things were done there. The only thing I noticed was that they used a
slightly different syntax.

So instead of:

default[‘chef_attribute_hell’][‘attr1’] = “attribute1"
default[‘chef_attribute_hell’][‘attr2’] =
”#{node.chef_attribute_hell.attr1}/attr2"
default[‘chef_attribute_hell’][‘attr3’] =
"#{node.chef_attribute_hell.attr2}/attr3"

They were doing it like this:

default[‘chef_attribute_hell’][‘attr1’] = “attribute1"
default[‘chef_attribute_hell’][‘attr2’] =
”#{node[‘chef_attribute_hell’][‘attr1’]}/attr2"
default[‘chef_attribute_hell’][‘attr3’] =
"#{node[‘chef_attribute_hell’][‘attr2’]}/attr3"

I tried that in my cookbook and voila… now everything seems to work.

Still not quite sure how the different syntaxes affect the compile time of
the node attribute map but hey, at least now it works.

Kind regards and merry Christmas,
Stefan Freyr.


From: Stefán Freyr Stefánsson
Sent: Tuesday, December 23, 2014 11:00 AM
To: chef@lists.opscode.com
Subject: Re: [chef] Re: attributes constructed from other attributes
aren’t added to the attribute map

Hi.

Thanks for your answer. Unfortunately I’m not quite sure if I’m
understanding it correctly, at least my understanding of the fix does not
work.

What I did was I added ‘node.’ in front of my 'default[‘foo’][‘bar’] =
…" in the attributes/default.rb file in my cookbook. Here are the full
contents of the file as they stand after the change:

node.default[‘chef_attribute_hell’][‘attr1’] = “attribute1"
node.default[‘chef_attribute_hell’][‘attr2’] =
”#{node.chef_attribute_hell.attr1}/attr2"
node.default[‘chef_attribute_hell’][‘attr3’] =
"#{node.chef_attribute_hell.attr2}/attr3"

This still results in:

   NoMethodError
   -------------
   Undefined method or attribute `attr2' on `node'

   Cookbook Trace:
   ---------------

/tmp/kitchen/cookbooks/chef_attribute_hell/attributes/default.rb:3:in
`from_file’

   Relevant File Content:
   ----------------------
   /tmp/kitchen/cookbooks/chef_attribute_hell/attributes/default.rb:

     1:  node.default['chef_attribute_hell']['attr1'] = "attribute1"
     2:  node.default['chef_attribute_hell']['attr2'] =

“#{node.chef_attribute_hell.attr1}/attr2"
3>> node.default[‘chef_attribute_hell’][‘attr3’] =
”#{node.chef_attribute_hell.attr2}/attr3"
4:

Finally, you say that this is a “very rare edge case”. All I did was make
a cookbook with attributes that are constructed from values of previous
attributes. Is that really an edge case? Is there some other way to
accomplish the same thing? Because this seems like a bit of a fundamental
thing to me.

Kind regards, Stefan Freyr.


From: AJ Christensen aj@junglistheavy.industries
Sent: Monday, December 22, 2014 7:19 PM
To: chef@lists.opscode.com
Subject: [chef] Re: attributes constructed from other attributes aren’t
added to the attribute map

The syntax is not wrong, this is unfortunately a very rare edge case
with the way that attribute reads are evaluated.

You can move any computed attributes to the Recipe’s Compile Phase in
order to Not Be Bitten By Things., e.g.:

node.default['chef_attribute_hell']['attr2'] = "#{...}/..."
node.default['chef_attribute_hell']['attr3'] =
"#{node.chef_attribute_hell.attr2}/attr3"

I wish the notes from the “Attributes WAT” community session had been
captured but it was a very high energy discussion – we went into the
details as to what causes this to occur. Something to do with the
"read time" of the attributes in the attributes DSL being before some
attribute precedence resolution happens, I fear, although I don’t
recall. HTH.

cheers,

–aj

On Tue, Dec 23, 2014 at 7:38 AM, Stefán Freyr Stefánsson
stefan@nextcode.com wrote:

Hi.

I just started using test-kitchen again after a bit of a break. I was
surprised to find out that a very simple internal cookbook that we’ve
been
using now didn’t work.

The error occurred when evaluating our default attribute file. It was
complaining about an attribute (attr3) that was composed with the value
of
another attribute (attr2), which in turn was composed from the value of
another attribute (attr1). After adding some “raise” lines to the
default.rb
attribute file in our cookbook and a test recipe we were able to
determine
that attr1 was added to the map, while attr2 was not added and trying to
construct attr3 then resulted in a failure.

Sorry for the convoluted explanation, I make some sad attempt to describe
this here: https://gist.github.com/StFS/2a333afe352d0dc8cbb5

As I said I was using test-kitchen for this and in my .kitchen.yml file I
had:
require_chef_omnibus: true

This installed Chef 12.0.3-1 on the vagrant machine (which is a CentOS
7).
Since this had been working previously I dug around a bit and noticed
that
all of our earlier installations seemed to be using version 11 of Chef.
So I
changed my .kitchen.yml file to specify version 11 of chef and now at
least
I’m getting further and the attributes map seems to be built correctly
in my
recipe.

So my question is, is the following syntax for my attribute file in some
way
wrong? If so, what should I be using? If the syntax is not wrong, is this
then a bug in Chef 12? Has it been reported (I didn’t find anything
during
my googling around for this problem)?

Here is an example of an attribute file that would fail:

default[‘chef_attribute_hell’][‘attr1’] = “attribute1"
default[‘chef_attribute_hell’][‘attr2’] =
”#{node.chef_attribute_hell.attr1}/attr2"
default[‘chef_attribute_hell’][‘attr3’] =
"#{node.chef_attribute_hell.attr2}/attr3"

Kind regards,
Stefan Freyr

p.s. I can make a full blown cookbook with a .kitchen.yml file available
which demonstrates this problem if needed.