Noah and Three,
I've appreciated your insights and have some good ideas for moving forward. Thanks.
Wazza
Warren Bain
http://ninefold.com
Australia's cloud
direct: +61 2 8221 7729
mobile: +61 414 867 559
follow: http://twitter.com/thoughtcroft
Noah Kantrowitz noah@coderanger.net wrote:
Just keeps the application declaration to be only the data side of the equation, rather than mixing description and code. Matter of personal taste I suppose.
--Noah
On Dec 4, 2012, at 6:03 PM, Three Tee wrote:
Cool, duplicating the LWRP makes sense. Besides the potential for code reuse, are there other reasons to prefer an app-specific LWRP over adding chef code to a callback in this case?
On Dec 4, 2012, at 5:50 PM, Noah Kantrowitz noah@coderanger.net wrote:
The way the application cookbook was built is to allow customizing those kinds of things very closely. You can just copy that LWRP (the application_ruby_memcache one) into a cookbook of your own and customize it, and then in the main application do end block refer to myapp_memcache instead. Nice and modular
--Noah
On Dec 4, 2012, at 5:36 PM, Three Tee wrote:
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:
Noah,
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:
https://github.com/opscode-cookbooks/application_ruby/blob/master/providers/memcached.rb#L28
Wazza
From: Noah Kantrowitz [noah@coderanger.net]
Sent: Wednesday, 5 December 2012 10:07 AM
To: chef@lists.opscode.com
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
--Noah
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?
Regards,
Wazza
