Sorry for the new thread. I’m going to take another stab at this.
We have servers in several physical locations. Each has different
attributes. We’re currently implementing some of these attributes (mostly
host addresses and such) with one role per location. A portion of the
attributes set in the role for one of these locations (us4) looks like this:
"default_attributes": {
"couchbase": {
"servers": ["changeme", "changeme"]
},
"redis": {
"master": "redis01-us4.foobar.net",
"slave": "redis02-us4.foobar.net"
},
"mysql": {
"host": "dbproxy01-us4.foobar.net",
"master": "db-foobar.cptuvxysk1b5.us-west-1.rds.amazonaws.com"
},
"rabbitmq": {
"server": "mbus01-us4.foobar.net"
},
"memcache": {
"servers": ["memc01-us4.foobar.com", "memc02-us4.bitcasa.com"]
},
"rsyslog": {
"server_ip": "logs01-us4.foobar.net",
"protocol": "udp",
"remote_logs": true
},
"graphite": {
"server": "carbon",
"graphite_port": "2003",
"port": "8125",
"mgmt_port": "8126"
},
This approach bothers me because changing an attribute here referenced by
any cookbook will break those referencing cookbooks. This makes the
cookbooks brittle.
I suppose I could break the file into smaller pieces along the lines of
couchbase_us4.json, redis_us4.json, mysql_us4.json and so on. That would at
least make it clearer which services which files belong to.
It’s been recommended to me that we use location based cookbooks instead of
roles. I haven’t seen any objective reasons why yet. I also don’t see how
that would make the cookbooks any less brittle. The attributes as defined
could still be referenced by several other cookbooks and break when the
attribute changes. Putting attributes into a location cookbook would also
mean we’d have to define them with ruby, which is less readable than json.
‘Don’t do that.’ could be said in response to us changing the attributes,
but we’re still changing things frequently and trying to stabilise.
Doug.
–
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garstang@gmail.com
Cell: +1-805-340-5627