By the way, I've been using the ruby manifests and its great cause I can use ruby in the manifests 
I.e. I can have blocks of ruby before the main manifest attributes to build up hashes and then use them in the spice weasel sections. Both as pure ruby and thru ruby string interpolation.
This is especially helpful for passing in json blobs to set chef override attributes instead of or in addition to using roles.
So a "preamble" section sets up a bunch of global and specific overrides:
"Global" attributes that should be applied to all nodes
cluster_attributes = {
:cluster_name => "qa00"
}
Hash of each attributed override for each node
overrides = {
The pod Node
:pod_attributes => {
:pod => "default",
:haproxy => {
:balance_algorithm => "hdr(X-Real-IP)",
:defaults_options => [
"httplog",
"dontlognull",
"forwardfor",
"redispatch",
"httpchk GET /ui/"
]
},
:logstash => {
:awesant=> {
:inputs => [
{:file =>{
:type => 'secure',
:path => '/var/log/secure',
} }
]
}
}
},
The cluster nodes
:cluster_attributes => {},
The engine app nodes
:engine_attributes => {}
}
Merge the cluster level overrides into the individual overrides
overrides.each_pair { |k,v| overrides[k].merge!(cluster_attributes) }
Then in the spice weasel section I can say things like #{overrides[:pod_attributes].to_json} to set the Json attributes passed into the chef run:
"clusters"=>
[
{
"qa"=>
[
{
"ec2 1"=>
{
"run_list"=>"role[pod] recipe[pod] recipe[logstash::awesant]",
"options"=>
"-d chef-full -S qa00-east1 -G qa00 -I ami-ac6d9172 -f m1.medium -j '#{overrides[:pod_attributes].to_json}' -N qa_plb{{n}}.app.example.com"
}
},
...
Robert J Berger +1 408-838-8896
Internet Bandwidth Development, LLC
http://www.linkedin.com/in/rberger
On Aug 9, 2013, at 10:13 AM, Matt Ray matt@opscode.com wrote:
Thanks for the spiceweasel shoutout, I'm readying the 2.6 release right now which will add the ability to upload nodes if you're storing them as JSON files (Vagrant users requested the feature). It actually handles a pretty wide variety of use cases, the intention has always been to give you a manifest to understand how to deploy/recreate a set of Chef infrastructure. If you don't like YAML you can also use JSON or Ruby formats for your manifests
Thanks,
Matt Ray
Cloud Integrations Product Lead :: Opscode
512.731.2218 :: matt@opscode.com
mattray :: GitHub :: IRC :: Twitter
From: steve . leftathome@gmail.com
Sent: Thursday, August 08, 2013 2:43 PM
To: chef@lists.opscode.com
Cc: Brad Knowles
Subject: [chef] Re: Re: Manage role-node association with scm?
One way of expressing, say, a cluster or group of machines using something SCM-able is to use spiceweasel, which basically converts a YAML file into a bunch of knife commands. Different people seem to use it in different ways (for example, I use it to set up a Chef server with all the objects in a Chef repository for testing), but maybe this will give you some ideas. Or at least a keyword to search against. 
Check it out:
GitHub - mattray/spiceweasel: Generates Chef knife commands from a simple JSON or YAML file.
On Thu, Aug 8, 2013 at 7:31 AM, Brad Knowles brad@shub-internet.org wrote:
On Aug 8, 2013, at 8:33 AM, Tommaso Visconti tommaso.visconti@gmail.com wrote:
knife node run_list add "role[cool_role]"
but this doesn't leave any trace in the chef-repo files, so it's impossible to save the associations in the SCM.
Is it possible to use ruby/json files to manage the nodes' roles? Or the only ways are knife and the chef-server web interface?
Well, "knife role from file" will get you the roles themselves stored in a format that you can check into the SCM, but that doesn't help with the information about the nodes and what roles have been applied to them.
What I've done in the past is to do a "knife node edit" any time I wanted to add a role or delete a role from a node, or otherwise make changes to the runlist on a node. But you're right that this information isn't checked into an SCM anywhere. You could dump the information from a "knife node show nodename -l" into a file format that could be checked into an SCM, but most of the information will be auto-discovered by ohai, and you really want to let ohai do the job you're asking it to do.
For my part, I considered this information about the node itself to be fairly ephemeral, and the information available from the Chef database regarding the roles, runlists, and other details about a node has been sufficient. So long as Chef keeps track of what is applied to what node, I haven't really cared.
I tried to solve the problem reading the docs, but they are really a lot and I didn't find anything useful for this 
The search interface on docs.opscode.com is decent, but it definitely has limits. If you know a keyword or two, that's usually enough to get you to a set of pages, one of which is likely to have information that leads you to an answer for your question. But if you don't know what you're looking for, or it's more specific than can be crammed into just a keyword or two, then you're less likely to be successful.
--
Brad Knowles brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu
