Cookbook standardizations

[mrflip]

We should standardize a few things that are mostly-agreed on, but still have some variation.

default, client, server

Recipes should differentiate between client and provider recipes (the redis recipe is one notable offender). Taking redis as an example,

• recipes/default information shared by anyone using redis
• recipes/client configure me as a client of a redis facet
• recipes/server configure me as a server of a redis facet

We should standardize these names and that separation across the cookbooks. The redis recipe has the dangerous situation that including the 'redis' recipe makes you a server. We need to make sure that's not the case

include_recipe

Use include_recipe:

• only if putting it in the role would be utterly un-interesting.
• never for anything that will start a daemon

If you leave it out, it will break unless I include the recipe in my role: this is a GOOD thing. include_recipe yes: java, ruby, cluster_service_discovery, etc. include_recipe no: zookeeper:client, nfs:server.

fooservice/thingy, not fooservice/fooservice_thingy

Recipes shouldn't repeat their service name: 'hbase:master' and not 'hbase:hbase_master'; 'zookeeper:server' not 'zookeeper:zookeeper_server'.

node[:cluster_name] vs node[:service][:cluster_name]

Right now recipes disorganizedly reference either

• the scoped cluster name: node[:zookeeper][:cluster_name]
• the cluster name node[:cluster_name] directly

Cluster identity is currently used to reference

• the cluster I am a member of
• for a service I provide, the cluster I represent
• for a service I consume, the cluster I am patronizing.

The first two DO seem to be identical, but the third is different and shouldn't use the word 'cluster_name'. Proposed that recipes reference:

• the scoped cluster name: node[:zookeeper][:providing_cluster] if present
• the cluster name node[:cluster_chef][:cluster] otherwise

so with a new method

def cluster_providing(service_scope, service_role=nil)
  service_role ||= service_scope
  providing_cluster = (node[service_scope][:providing_cluster] || node[:cluster_chef][:cluster])
  "#{providing_cluster}-#{service_role}"
end

then if cluster hambone had

  :zookeeper => { :providing_cluster => 'turkey' },
  :redis     => { },
  :cassandra => { },

you would say

  private_ip_of(cluster_providing(:zookeeper))                   # "turkey-zookeeper"
  private_ip_of(cluster_providing(:redis}                        # "hambone-redis"
  private_ip_of(cluster_providing(:cassandra, 'cassandra-seed')) # "hambone-cassandra-seed"

[temujin9]

I've seen it recommended (and I agree) that recipes should separate the tasks that install a piece of software from the tasks that start it. Chris points out that this will also allow service-testing based on what services a role is configured to have running.

So redis' recipes would be redis:default, redis:client, redis:server, redis:runserver, and redis:runclient (if it contains daemon(s) that should be invoked).

[mrflip]

+1

[mrflip]

Progress report -- the attribute standardization is in place. @temujin9 will perform final checklist review in burndown to v3 release.

[temujin9]

@mrflip: awesome, thank you.

@aseever: can you make me a PT ticket for this? Thanks.