Ok Here we go!
Beyond the old approach (where the user would build recipes as new Recipe(ck,rcp) which could be added as statements) the service now supports doing everything by configuration.
The first instance template to use the "chef" role will trigger the installation of ruby and chef.
In the instance templates now the following usages are supported:
chef only: "1 chef" installs chef but runs no cookbooks (as was before)
chef with default cookbook: "1 chef:java" in this case chef installs chef, the cookbook and runs the default recipe.
chef with particular recipe: "1 chef:java:sun" as before but for a particular recipe.
passing attributes through configuration: attributes were already supported in the Recipe but they now can be specified by configuration as
There is only a special case, when the attribute_name is "url" in this case the cookbook will be fetched from the url (vs using the default cookbooks).
A final note attribute values can be anything that would possible in a typical chef ruby definition file which is usually json
As recipes are long running scripts, using recipes outside of handlers required a change to ClusterController where Adrian introduced runScriptOnNodesMatching method that supported passing RunScriptOptions. I commented out the portion of the tests that used this as this change, to be introduced (and in IMHO it should because it is useful), should probably go on another jira.
Finally I ran unit tests and pretty extensive sys tests with the dry run module but I'm still missing itests.