Class | Chef::Node |
In: |
lib/chef/node/attribute.rb
lib/chef/node.rb |
Parent: | Object |
DESIGN_DOCUMENT | = | { "version" => 9, "language" => "javascript", "views" => { "all" => { "map" => <<-EOJS function(doc) { if (doc.chef_type == "node") { emit(doc.name, doc); } } EOJS |
automatic_attrs | [RW] | |
cookbook_collection | [RW] | TODO: 5/18/2010 cw/timh. cookbook_collection should be removed from here and for any place it‘s needed, it should be accessed through a Chef::RunContext |
couchdb | [RW] | |
couchdb_id | [R] | |
couchdb_rev | [RW] | |
default_attrs | [RW] | |
normal_attrs | [RW] | |
override_attrs | [RW] | |
recipe_list | [RW] | |
run_list | [RW] | |
run_state | [RW] |
List all the Chef::Node objects in the CouchDB. If inflate is set to true, you will get the full list of all Nodes, fully inflated.
Return true if this Node has a given attribute, false if not. Takes either a symbol or a string.
Only works on the top level. Preferred way is to use the normal [] style lookup and call attribute?()
Extracts the run list from attrs and applies it. Returns the remaining attributes
Expands the node‘s run list and deep merges the default and override attributes. Also applies stored attributes (from json provided on the command line)
Returns the fully-expanded list of recipes.
TODO: timh/cw, 5-14-2010: Should this method exist? Should we instead modify default_attrs and override_attrs whenever our run_list is mutated? Or perhaps do something smarter like on-demand generation of default_attrs and override_attrs, invalidated only when run_list is mutated?
Find a recipe for this Chef::Node by fqdn. Will search first for Chef::Config["node_path"]/fqdn.rb, then hostname.rb, then default.rb.
Returns a new Chef::Node object.
Raises an ArgumentError if it cannot find the node.
Encouraged to only get used for lookups - while you can do sets from here, it‘s not as explicit as using the normal/default/override interface.