Hi All,

I created a JIRA ticket. Apologies in advance if I've committed any sins
categorizing and tagging it (would be happy to fix them if so):
https://issues.apache.org/jira/browse/BIGTOP-2467

@Roman: hi. Thank you for the detailed reply :-)

Theoretically, you can add nodes to the ZK cluster (provided that you
> increment
> the identity ID) but if the node goes down you have to maintain the
> identity
> mapping somehow. Which leads to a situation where most ZK cluster are very
> static in nature. You only bring nodes back from the dead -- you don't
> really
> scale cluster up and down.
>

I think that the juju charm I'm working on can help solve some of the
technical issues with scaling up and down. We have a mapping of unique ids
in the form of the unit id that we track for each node, and handlers for
the cases where nodes come up or go down. What I'd like to do is change the
list the puppet script expects to find in its ensemble variable from this:

["<some ip>:2888:3888", "<some other ip>:2888:3888"]

To this:

[[<some id>, "<some ip>:2888:3888"], [<some other id>, "<some other
ip>:2888:3888"]]

I think that helps you out in cases where you're not using a charm, too, as
you can determine your ids and ips in advance, and then pass a correctly
ordered and identified list to puppet on each node.

If that sounds reasonable, I'll go ahead and submit a patch.


> I haven't seen anybody use that in production. What do you need it for?
>

My goal was to write a generic charm that did all the things somebody might
want to do with Zookeeper. The pre-Bigtop charm had a "start rest" and
"stop rest" action in it. For now, I think that I'm going to deprioritize
REST, because everybody tells me that people don't really use it. :-)

Thank you,
~ PeteVG

Reply via email to