Be able to use chef attributes in serverspec

[guilhem]

For now we are using tests to manage if executable is installed with:

describe command('which nodejs') do
  it { should return_exit_status 0 }
end

But that's quite limited, we don't know if version installed is what we really want. Something really good can be to be able to use:

describe command('nodejs -v') do
  it { should return_stdout "v#{node['nodejs']['version']}" }
end

It can be related to this: https://github.com/serverspec/serverspec/issues/155

I don't know if it must be manage by serverspec (be able to parse chef), or a work for busser to be able to export in serverspec yml format. But this feature is clearly a must-have.

PS: If it's already possible, don't hesitate to tell me how :) PS bis: another ticket talk about it... but I really don't understand why using chef attributes in tests is a bad idea... really

[d-higuchi]

busser-serverspec does not have this feature, because test-kitchen and busser do not support this. so i think some trick is needed for your want. ticket you mentioned and these tests maybe your help.

[sawanoboly]

HI, @guilhem

I also thought the same thing with it :confounded:

And I use ohai like this.

https://github.com/megumiteam/chef-amimoto/blob/master/test/integration/amimoto/serverspec/spec/spec_helper.rb

[guilhem]

I'm quite disappointed :disappointed: to not see this in test.

Ohai is good, but what I want (and anyone too??) is to test if my cookbook do it must.

If I set version to install in my cookbook, it's quite logic to test if this version is installed (and I don't want to duplicate configuration between attributes and tests).

:disappointed_relieved:

[sawanoboly]

@guilhem

hmm.. How about a json report? (chef-handler)

http://docs.opscode.com/handlers.html

And read newest json report at spec_helper.

[mikelococo]

@cl-lab-k What's the closure status on this: closed/fixed, closed/wontfix, or closed/there-is-a-bug-elsewhere-to-write-a-json-attribute-report? I'm also keenly interested in using node attributes in my test-kitchen/busser driven serverspec tests.

[d-higuchi]

wontfix. but you can use node attributes to write suitable tests. see above examples.

[jakshi]

http://jakshi.com/blog/2014/05/12/accessing-chef-attributes-in-serverspec-tests/

[renier]

Much easier. Just put this in a spec support file and require it from your tests:

class MyHash < Hash
  alias_method :orig_subscript, :'[]'
  define_method(:'[]') do |subscript|
    send(:'[]=', subscript, MyHash.new) unless orig_subscript(subscript)
    orig_subscript(subscript)
  end
end

default = node = override = MyHash.new

eval IO.read('/tmp/kitchen/cookbooks/my_cookbook/attributes/default.rb')

# default hash has all the values now.

However, this will not get you all the node attributes. Just the ones in the cookbook(s) you are testing.

[xacaxulu]

I would move to using control_groups with the latest Chef 0.5.0 release candidate. You can do away with serverspec and simply write in-line control_group audits, which are an abstraction of serverspec.

https://docs.chef.io/analytics.html#controls

[BBK-PiJ-2015-14]

Combination of cookbook attributes and kitchen suite attributes would be ideal. This way you get whatever both cookbook specific and can add any rutime attributes or have different ones depending on which suite you execute.

Would anyone know how to retrieve suite attributes inside of custom spec type?

` suites:

• name: default run_list:
  • recipe[my_windows_cookbook::default] attributes: { 'NodeA': { 'AttributeZZ':'ValueZZ', 'NodeAA': { 'AttributeXX' : 'ValueXX' } } }

`

[xmik]

There is a solution, described here: https://github.com/test-kitchen/test-kitchen/issues/858 , but do read the last comment from there too.