Skip to content

Instantly share code, notes, and snippets.

@pburkholder
Created May 13, 2015 15:54
Show Gist options
  • Select an option

  • Save pburkholder/7b6b35ae1229dbd44d9e to your computer and use it in GitHub Desktop.

Select an option

Save pburkholder/7b6b35ae1229dbd44d9e to your computer and use it in GitHub Desktop.
Attributes thinking...

Here's some of my thinking attributes:

  • use default levels, except when you can't

  • think of attributes in two ways

    • as the interface to the cookbook
    • as attributes of the node (not as variable in the cookbook)
      • e.g. node.network.ip - is a fact about the node
      • node.users.sudoers - is an attribute you are setting because you want it to be a fact
  • avoid ruby logic in attributes/default.rb

  • remember that attributes/*.rb all get consumed upon cookbook load

    • I used to think attributes/foo.rb was only consumed by recipe/foo.rb
      • They are loaded in alpha order
  • it can be useful to hide library attributes from your internal consumers:

What I'm wondering about also is 'proxying' of attributes, supposing I want an 'our_logstash' site cookbook to set sane default for logstash, but which logserver to use may depend on the group or env that uses it, so I've done this is in the past:

default[:our_logstash][:logserver] = 'l.example.com'
default[:logstash][:logserver] = node.default[:our_logstash][:logserver]



Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment