[chef] Re: Re: Re: RE: Re: Memcached on a separate node?


Chronological Thread 
  • From: Three Tee < >
  • To: " " < >
  • Cc: " " < >
  • Subject: [chef] Re: Re: Re: RE: Re: Memcached on a separate node?
  • Date: Tue, 4 Dec 2012 18:03:38 -0800

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 
< >
 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:
>> 1. A single rails server with a local memcache
>> 2. 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 
>> < >
>>  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 
>>> 
>>> Sent: Wednesday, 5 December 2012 10:07 AM
>>> To: 
>>> 
>>> 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
> 



Archive powered by MHonArc 2.6.16.

§