mikerhodes commented on issue #1338: Configuring node "flavors" in a cluster URL: https://github.com/apache/couchdb/issues/1338#issuecomment-399937812 Thoughts on config, I'd likely go for something that put the node's "role" as a single config concept in some manner, either: ``` [node] roles = coordinator,replicator,storage ``` or: ``` [node-roles] coordinator = true ; listens on HTTPS, issues fabric requests replicator = false ; will not mediate any replication jobs storage = false ; will not store any user data ``` What would happen to existing clusters if we expand the role set? I can see the true/false approach handles this quite simply by defaulting true. For @iilyak: > over time move authentication and authorization modules to api node so unauthorized requests do not reach storage layer at all I am definitely for this approach. I think consolidating access checks makes it easier to be confident in the security properties of the system and makes unit testing many combinations simpler. For @nickva: > That would be great to have, and it would open the door to auto-resharding (but that's for a different discussion). I think it opens the door to automatic _rebalancing_ of shards rather than _resharding_ (isn't that about increasing or decreasing the number of shards for a given database?). A key thing for me about this is allowing a shard replica itself to be able to flag its (including primary data and indexes) "readiness state". > It is also interesting to think about what happens during membership changes. I think dealing with this scenario is likely very important, even if it's along the lines of a refusal to change one's role within a cluster. The semantics otherwise end up quite subtle (e.g., `storage` -> `api` is hard to detect because the replication factor of a shard decreases but you still likely have copies in service). > `_replicator` db shards placement is customized such that _replicator docs end up only on replicator nodes. I would likely put them into the storage nodes, as they'd be what you'd be backing up in this scenario.
---------------------------------------------------------------- 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: [email protected] With regards, Apache Git Services
