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

[Noah Kantrowitz < >]

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 
> <
 >
>  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
>>