Overriding conditional attributes in a wrapper cookbook?

Chef Infra (archive)
1

Hi,

I’m trying to write a wrapper cookbook for postfix, with the intention of
just setting some attributes for my organisation. However, some of the
attributes defined in the postfix cookbook are ‘conditional’ i.e. whether
they’re defined depends on values of other attributes. That decision is
being made when postfix’s attributes/default.rb file is processed, which is
before the attributes for my wrapper are processed, and so (some of) the
attributes I’m setting in the wrapper are being ignored. Well, not ignored
exactly: their values are updated, but the values of attributes defined
conditionally on them are not.

Here’s a concrete example. The postfix cookbook has an
attributes/default.rb file with:

if node[‘postfix’][‘main’][‘smtp_sasl_auth_enable’] == ‘yes’
…
default[‘postfix’][‘main’][‘smtp_sasl_security_options’] = ‘noanonymous’
…
end

In my wrapper I added an attributes/default.rb file with:

override[‘postfix’][‘main’][‘smtp_sasl_auth_enable’] = ‘yes’

but, when the postfix recipe is run the
node[‘postfix’][‘main’][‘smtp_sasl_auth_enable’] value is not being defined
i.e. my override has not fully taken effect.

Is there a way to set the node[‘postfix’][‘main’][‘smtp_sasl_auth_enable’]
value from my wrapper
such that node[‘postfix’][‘main’][‘smtp_sasl_security_options’] =
‘noanonymous’ is declared as in
the postfix cookbook?

I did find the documentation about reloading attributes[1], but updating my
recipes/default.rb file
to:

ruby_block ‘some_code’ do
block do
node.from_file(run_context.resolve_attribute(“postfix”, “default”))
end
action :create
end

include_recipe 'postfix::default’
include_recipe ‘postfix::sasl_auth’

didn’t seem to help. What am I doing wrong?

Thanks in advance,

Mick

[1]
http://docs.opscode.com/essentials_cookbook_recipes.html#reload-attributes

–
Mick Brooks - mick.brooks@sinking.in
http://www.accu.org/ - Professionalism in Programming

2

Hi Mick,
as per our understanding this kind of scenario can be managed by overriding
both attributes that and their "dependencies" in wrapper cookbook.
In your case you could do, for example:

  • in your_wrapper_cookbook/attributes/default.rb:

default['your_wrapper_cookbook']['postfix']['main']['smtp_sasl_auth_enable']
= 'yes'
if
node['your_wrapper_cookbook']['postfix']['main']['smtp_sasl_auth_enable']
== 'yes'

default['your_wrapper_cookbook']['postfix']['main']['smtp_sasl_security_options']
= 'noanonymous'
end

...and so on

  • in your_wrapper_cookbook/recipes/default.rb:

node.override['postfix']=node.default['your_wrapper_cookbook']['postfix']
include_recipe 'postfix'

...and so on

Anyway I'm interested to know if is it possibile to achieve the same result
in a more elegant/efficient way too :slight_smile:

Cheers,
Marco

Il 08/feb/2014 03:18 "Mick Brooks" mick.brooks@sinking.in ha scritto:

Hi,

I'm trying to write a wrapper cookbook for postfix, with the intention of
just setting some attributes for my organisation. However, some of the
attributes defined in the postfix cookbook are 'conditional' i.e. whether
they're defined depends on values of other attributes. That decision is
being made when postfix's attributes/default.rb file is processed, which is
before the attributes for my wrapper are processed, and so (some of) the
attributes I'm setting in the wrapper are being ignored. Well, not ignored
exactly: their values are updated, but the values of attributes defined
conditionally on them are not.

Here's a concrete example. The postfix cookbook has an
attributes/default.rb file with:

if node['postfix']['main']['smtp_sasl_auth_enable'] == 'yes'
...
default['postfix']['main']['smtp_sasl_security_options'] = 'noanonymous'
...
end

In my wrapper I added an attributes/default.rb file with:

override['postfix']['main']['smtp_sasl_auth_enable'] = 'yes'

but, when the postfix recipe is run the
node['postfix']['main']['smtp_sasl_auth_enable'] value is not being defined
i.e. my override has not fully taken effect.

Is there a way to set the
node['postfix']['main']['smtp_sasl_auth_enable'] value from my wrapper
such that node['postfix']['main']['smtp_sasl_security_options'] =
'noanonymous' is declared as in
the postfix cookbook?

I did find the documentation about reloading attributes[1], but updating
my recipes/default.rb file
to:

ruby_block 'some_code' do
block do
node.from_file(run_context.resolve_attribute("postfix", "default"))
end
action :create
end

include_recipe 'postfix::default'
include_recipe 'postfix::sasl_auth'

didn't seem to help. What am I doing wrong?

Thanks in advance,

Mick

[1]
About Recipes

--
Mick Brooks - mick.brooks@sinking.in
http://www.accu.org/ - Professionalism in Programming

3

Hi Marco,

Thanks for your reply.

On Sat, Feb 8, 2014 at 9:04 AM, Marco Betti m.betti@gmail.com wrote:

as per our understanding this kind of scenario can be managed by
overriding both attributes that and their "dependencies" in wrapper
cookbook.
In your case you could do, for example:

Ah, yes. I can see how that could work, but I hesitate to start duplicating
logic from another cookbook (even
when it's very simple).

Anyway I'm interested to know if is it possibile to achieve the same result

in a more elegant/efficient way too :slight_smile:

Let's hope someone knows a better way :slight_smile:

Cheers,

Mick

--
Mick Brooks - mick.brooks@sinking.in
http://www.accu.org/ - Professionalism in Programming

4

Hi Mick,

the documentation in [1] should work, but probably you should try it
without the ruby_block so it runs at compile time:

node.from_file(run_context.resolve_attribute("postfix", "default"))

include_recipe 'postfix::default'
include_recipe 'postfix::sasl_auth'

Does that work for you?

Cheers, Torben

On Sat, Feb 8, 2014 at 3:18 AM, Mick Brooks mick.brooks@sinking.in wrote:

Hi,

I'm trying to write a wrapper cookbook for postfix, with the intention of
just setting some attributes for my organisation. However, some of the
attributes defined in the postfix cookbook are 'conditional' i.e. whether
they're defined depends on values of other attributes. That decision is
being made when postfix's attributes/default.rb file is processed, which is
before the attributes for my wrapper are processed, and so (some of) the
attributes I'm setting in the wrapper are being ignored. Well, not ignored
exactly: their values are updated, but the values of attributes defined
conditionally on them are not.

Here's a concrete example. The postfix cookbook has an
attributes/default.rb file with:

if node['postfix']['main']['smtp_sasl_auth_enable'] == 'yes'
...
default['postfix']['main']['smtp_sasl_security_options'] = 'noanonymous'
...
end

In my wrapper I added an attributes/default.rb file with:

override['postfix']['main']['smtp_sasl_auth_enable'] = 'yes'

but, when the postfix recipe is run the
node['postfix']['main']['smtp_sasl_auth_enable'] value is not being defined
i.e. my override has not fully taken effect.

Is there a way to set the node['postfix']['main']['smtp_sasl_auth_enable']
value from my wrapper
such that node['postfix']['main']['smtp_sasl_security_options'] =
'noanonymous' is declared as in
the postfix cookbook?

I did find the documentation about reloading attributes[1], but updating
my recipes/default.rb file
to:

ruby_block 'some_code' do
block do
node.from_file(run_context.resolve_attribute("postfix", "default"))
end
action :create
end

include_recipe 'postfix::default'
include_recipe 'postfix::sasl_auth'

didn't seem to help. What am I doing wrong?

Thanks in advance,

Mick

[1]
About Recipes

--
Mick Brooks - mick.brooks@sinking.in
http://www.accu.org/ - Professionalism in Programming

5

Hi Torben,

On Tue, Feb 11, 2014 at 7:38 PM, Torben Knerr ukio@gmx.de wrote:

the documentation in [1] should work, but probably you should try it
without the ruby_block so it runs at compile time:

Aha - thanks for this. Yes, that works perfectly. I couldn't see the wood
for the trees.

Everything begins to make more sense now - the example in the documentation
is in a ruby_block so
that it can be triggered by other actions (those that affect the values of
attributes, as described). I
mistakenly thought it was required for the node.from_file(...) to work.

Thanks again,

Mick

--
Mick Brooks - mick.brooks@sinking.in
http://www.accu.org/ - Professionalism in Programming