[chef] Location attributes.

[Douglas Garstang < >]

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: ">
Cell: +1-805-340-5627