Hello,
In absence of https://issues.apache.org/jira/browse/ZOOKEEPER-107 how do
people handle situations where ZK cluster membership needs to be a little
bit.... dynamic, let's say.
Here's the use case we have at Sematext:
* Our software ships on a VM.
* All components run in this single VM, including 1 ZK
* Of course, this is just for a nice OOTB experience, but to scale one
needs to have more instances of this VM, including more (3) ZK instances.
* *One can clone our VM and launch N instances of it, but that won't work
for ZK - we'd need to put ZK node IDs in ZK config files - and have a
different ID for each node*
This bold part above is problematic if one has just a single ZK config with
a single ID.
How do others handle this in a software that is packages and ships to user
and is not in yoru direct control to allow you to edit configs?
Thanks,
Otis
In absence of https://issues.apache.org/jira/browse/ZOOKEEPER-107 how do
people handle situations where ZK cluster membership needs to be a little
bit.... dynamic, let's say.
Here's the use case we have at Sematext:
* Our software ships on a VM.
* All components run in this single VM, including 1 ZK
* Of course, this is just for a nice OOTB experience, but to scale one
needs to have more instances of this VM, including more (3) ZK instances.
* *One can clone our VM and launch N instances of it, but that won't work
for ZK - we'd need to put ZK node IDs in ZK config files - and have a
different ID for each node*
This bold part above is problematic if one has just a single ZK config with
a single ID.
How do others handle this in a software that is packages and ships to user
and is not in yoru direct control to allow you to edit configs?
Thanks,
Otis