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