couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Vatamaniuc <vatam...@gmail.com>
Subject Re: [DISCUSS] Node types in CouchDB 4.x
Date Wed, 20 Nov 2019 06:31:35 GMT
Oh I remember that discussion now. I even commented on it :-). I'll have to
add a reference to it in the RFC.

Looking through the comments, it seems there would be some work involved in
backporting it to 3.x -- storage nodes becoming non-storage nodes, and some
redesign around how_replicator docs are monitored and updated...

For 4.x, most of it becomes trivial given how couch_jobs' API is already
split into a frontend and a backend part. There it's just a matter of
wrapping the startup of those parts in case statements to check if they
should be enabled or disabled.

I made a quick attempt at implementing it to see what it might look like in
a draft pr:

https://github.com/apache/couchdb/pull/2319

There are few changes needed to be made, like switching to using
application environment vars, as per Jan's suggestion, but I think it
capture the general idea for the 4.x implementation.

Cheers,
-Nick

On Tue, Nov 19, 2019 at 7:01 PM Adam Kocoloski <kocolosk@apache.org> wrote:

> I’ve long been a fan of this sort of thing — see
> https://github.com/apache/couchdb/issues/1338for an example ☺️
>
> Many of the node types are not really specific to the 4.0 architecture. I
> don’t know if anyone will be interested in backporting to the classic
> architecture, but API nodes, replicator nodes, etc. would definitely be
> relevant in 3.x.
>
> Adam
>
> > On Nov 19, 2019, at 11:54 AM, Nick Vatamaniuc <vatamane@gmail.com>
> wrote:
> >
> > 
> >> Isn’t it an approach used by Couchbase?
> > https://docs.couchbase.com/server/current/clustersetup/services-mds.html
> >
> > Thanks for the link. From taking a quick look over it, I think it is?
> > Though I am not familiar with exact terminology like "index" vs
> > "query" service in that context.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message