Release 1.0.0 with integration recipes (was: First stab at recipe-based configuration.)

[alq666]

Cassandra is in.

Role example:

role "cassandra"

run_list "cassandra", "datadog::cassandra"

If this is a viable option, the rest of the recipes will follow.

[alq666]

No need to merge yet, but curious about your thoughts.

[miketheman]

1. I like this
2. I suspect that having the yaml file actually as a template with attributes (port, username, etc) having sane defaults that can be expected to "always work", and overridable from elsewhere (role, env, et al) makes a little more sense
3. This kind of "migration" can also support namespacing the attributes to live under a 'datadog' node namespace - and not conflict with others, as we've seen before.
4. We could potentially include an 'auto-detect' recipe once we have 'component' recipes - it looks for the default attributes of a widely-used and well-known cookbook namespace and includes the correct recipe for that component. Maybe not immediately, but I suspect that adoption of 'it just works!' monitoring is benefiting somewhat from automatic config generation today.

[miketheman]

Some thoughts:

1. Use modern notification syntax FC043 (old style is deprecated)
2. Consider enclosing ERB conditionals with closing syntax to reduce rendered whitespace (see Datadog agent template renders a lot of whitespace #56)
3. LWRP name should be monitor.rb => datadog_monitor, cleaner than datadog_ddmonitor. Or possibly datadog_agentmonitor - but that's very long...
4. Currently, the :add action doesn't notify. Why not? Presumably something could subscribe to a datadog_monitor :add resource.
5. There seems to be inconsistency with the order to init_config vs instances - it probably doesn't matter to the agent, but we should choose one over the other for consistency.
6. This still doesn't cover how we would accomplish multiple instances per host, but that might be something we can have the agent handle. Potentially attempt to interrogate the filename first for the plugin name, if not immediately discernable, have an integration or plugin attribute at the top of the .yaml file that tells the agent what this is.
   This might be a simpler route than trying to write the same file each run and compare the generated output.
   We can speak on this via other channels if this isn't 100% clear.

Other:

• Current attributes.rb probably deserves a full sweep of cleanup
• Do we want to continue to use EPEL (which may surprise some people) or should we package up any dependencies we need for a given integration? Most recently seen was Redis 2.0 package vs pypi version for Slave monitoring.

[alq666]

@miketheman what's triggered thus far in Vagrantfile passes a vagrant provision run. I'm going to push and finish the rest on the plane or in Austin.

[miketheman]

@alq666 @MisterRayCo Please review the README and CHANGELOG - let me know if something eneds to be updated before I ship this code out to the world.

[MisterRayCo]

@miketheman looking good to me