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
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
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
The code looks a bit wonky, not sure why it only adds the current node if it matches when length==0, seems like a bug to me? Other than that it shouldn't be required to be another node.
--Noah
On Dec 4, 2012, at 4:23 PM, Warren Bain 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
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
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
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
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
On 12/4/12 2:54 PM, "Warren Bain" Warren@ninefold.com 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?
There is no requirement that memcached be on a separate node - if you want
to run on the same machine, have a party.
Adam