While the line of code that you highlighted does indeed exclude the local host from the search, the subsequent lines add the local host to the results if it has the memcache role and no other memcache nodes are returned by the search. This means that the application cookbook as written supports two scenarios when generating memcache.yml:
- A single rails server with a local memcache
- Any number of rails servers that use any number of external memcache servers (with no overlap between the two groups of servers)
The “right” way to architect your rails cache is probably a topic for another email, but if you require overlap between the rails and memcache servers, you’ll probably want to eschew the application cookbook’s memcache.yml generation altogether and add some of your own code to the before_deploy callback that generates the memcache.yml file to your spec.
Hope this helps!
On Dec 4, 2012, at 4:23 PM, Warren Bain Warren@ninefold.com wrote:
Perhaps I didn’t explain myself very well or I don’t understand your reply
The cookbook looks for a node that has whatever the role is called and which isn’t this node i.e. has to be a different node to the app server. See here:
From: Noah Kantrowitz [email@example.com]
Sent: Wednesday, 5 December 2012 10:07 AM
Subject: [chef] Re: Memcached on a separate node?
You just have to give it a role, there is no reason that role can’t be “www” or some such
On Dec 4, 2012, at 2:54 PM, Warren Bain wrote:
We are using the application cookbook to do Rails deployments.
I’m wondering about the logic around memcached which requires a separate node that is not the app node to be set up as a memcached master. I’m not expert in this area at all but the common wisdom from our Rails developers is that memcached should be on the app server, not a separate vm which would seem to defeat the purpose. In particular we are doing deployments across availability zones so the network costs is higher than on a same physical host vm.
Can someone in OpsCode explain why separate memcached node is the model?