[GitHub] kocolosk opened a new issue #1338: Configuring node "flavors" in a cluster

[GitBox <gi...@apache.org>]

kocolosk opened a new issue #1338: Configuring node "flavors" in a cluster
URL: https://github.com/apache/couchdb/issues/1338
 
 
   For a while now we’ve had this capability to control the placement of database shards on various nodes throughout a cluster by using the “zone” attribute of documents in the /nodes DB:
   
   http://docs.couchdb.org/en/2.1.1/cluster/databases.html?highlight=zone#placing-a-database-on-specific-nodes
   
   Recently I’ve been exploring whether we might benefit from introducing an ability for nodes in a cluster to further specialize in their roles; e.g., a pool of nodes in a cluster could be reserved just for HTTP processing and request coordination (but not data storage), another pool could mediate replication jobs, etc. I think there are a lot of benefits to this design in busy clusters, particularly that it improves the observability of each node in the cluster as the specific nature of the workload consuming resources on that node  is more clear.
   
   I think any work in this direction would benefit for a richer interface for labeling nodes with specific attributes. The current “zone" design has a couple of limitations that I see:
   
   1. `zone` is a single tag, whereas we may want to assign multiple labels / tags / roles to a node
   2. `zone`  can only be set once the node is up and running which complicates cluster setup
   
   I'd like to solicit input on an alternative design that would be more flexible and user-friendly. I would certainly recommend that we support setting these properties in our normal config files (although we may still find it important internally to copy them into `/nodes` so that every node in the cluster learns about the capabilities of its peers). One thought I have is introducing a new top-level configuration section like so:
   
   ```
   [node]
   coordinator = true ; listens on HTTPS, issues fabric requests
   replicator = false ; will not mediate any replication jobs
   storage = false ; will not store any user data
   zone = us-metro-1a
   ```
   
   Of course, `coordinator`, `replicator`, `storage` would all default to true which would recover the current configuration where all cluster nodes share in all workloads equally.
   
   What do you all think?

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services