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

[Warren Bain < >]

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