to have a situation where we just start a Zookeeper node
by giving it a list of known other Zookeeper nodes in the cloud. And then it
should take on to the life of its own.
Hope that the use case helps. I am really looking forward to this!
Allow dynamic changes to server cluster membership
looking forward to this!
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
Project: Zookeeper
Issue Type
documentation that you may have? I will start off a separte discussion thread
regarding this on the dev mailing list instead of having it over the jira.
Thanks.
Regards,
-Vishal
Allow dynamic changes to server cluster membership
--
Key
Hi Henry,
I just commented on the Jira. I would be happy to contribute.
Please advise on the current status and next steps. Thanks.
Regards,
-Vishal
Hi Vishal -
Great that you're interested in contributing! This would be a really neat
feature to get into ZK.
The documentation that exists is essentially all on the JIRA. I had a patch
that 'worked' but was nowhere near commit-ready. I'm trying to dig it up,
but it appears it may have gone to
Hi Henry,
Thanks for the info. I will spend some more time to understand the issues
before starting with the implementation. I will let you know if I have any
questions (which I am sure I will).
Just to clarify, by solved issue you mean from design perspective and not
from implementation right?
Hi Vishal -
That's right - design, not implementation!
I'd encourage you to share a design document once you feel you understand
exactly what's required. This is probably going to be complex patch and
reviewers will need a study guide :)
cheers,
Henry
On 3 May 2010 10:26, Vishal Kher
the answer to my question here:
http://www.mail-archive.com:80/zookeeper-dev@hadoop.apache.org/msg07382.html
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira
community,
I would like to know the status of issue ZOOKEEPER-107 (Allow dynamic
changes to server cluster membership) which is assigned to Henry Robinson
Is this the right forum to ask this question or should I post an update to
the bug report?
Thanks
-- Hari
Zookeeper community,
I would like to know the status of issue ZOOKEEPER-107 (Allow dynamic
changes to server cluster membership) which is assigned to Henry Robinson
Is this the right forum to ask this question or should I post an update to
the bug report?
Thanks
-- Hari
--
Henry Robinson
, there hasn't been a lot of demand for this.
Patrick
Hariharan Subramanian wrote:
Dear Zookeeper community,
I would like to know the status of issue ZOOKEEPER-107 (Allow dynamic
changes to server cluster membership) which is assigned to Henry Robinson
Is this the right forum to ask this question
FYI, Ben has been working on Netty integration with ZooKeeper. One of the
benefits of this is it provides encryption and certificate based connection
auth - which would be a great way (cert) to solve some of the security
issues highlighted in 107. So the pieces are there, interest is there,
available today, there hasn't been a lot of demand for this.
Patrick
Hariharan Subramanian wrote:
Dear Zookeeper community,
I would like to know the status of issue ZOOKEEPER-107 (Allow dynamic
changes to server cluster membership) which is assigned to Henry
Robinson
that there are
options
available today, there hasn't been a lot of demand for this.
Patrick
Hariharan Subramanian wrote:
Dear Zookeeper community,
I would like to know the status of issue ZOOKEEPER-107 (Allow dynamic
changes to server cluster membership) which is assigned to Henry
Robinson
, there hasn't been a lot of demand for this.
Patrick
Hariharan Subramanian wrote:
Dear Zookeeper community,
I would like to know the status of issue ZOOKEEPER-107 (Allow
dynamic
changes to server cluster membership) which is assigned to Henry
Robinson
Is this the right forum to ask this question
Dear Zookeeper community,
I would like to know the status of issue ZOOKEEPER-107 (Allow dynamic
changes to server cluster membership) which is assigned to Henry Robinson
Is this the right forum to ask this question or should I post an update to
the bug report?
Thanks
-- Hari
--
--… …--
.- .-. ..
COMMIT is
delivered locally if the new view doesn't include the leader. This will result
in a new election.
4.E. The leader will adjust the quorum size as per the new view
otherwise.
Allow dynamic changes to server cluster membership
/functional
document. I know it would help me alot.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
Project: Zookeeper
form G if G comes online a bit later.
Any simpler solutions?
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
Project
) at least one of them will know about a later view. Therefore there's also
no concern about resurrecting old views.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https
this discussion is really interesting, but we can we move the
discussion on the behavior of the observer to ZOOKEEPER-368? I'll add my
comments on the last set of comments there.
Allow dynamic changes to server cluster membership
--
Key
sending a
PROPOSAL to everyone, including the observers. As observers will receive the
COMMIT as well, we have higher message complexity. For now, I'm good either
way.
Allow dynamic changes to server cluster membership
--
Key
, not necessarily to include
themselves. So an Observer attaches to a leader, syncs and maybe listens in on
the proposal stream for a while and then upgrades itself by issuing a view
change request.
Allow dynamic changes to server cluster membership
with the leader, it can simply
submit a setData. This way we have no special code path for this operation.
Only when finalizing the setData operation we have to update all appropriate
data structures.
Allow dynamic changes to server cluster membership
finding that any new follower can join an existing ensemble
and issue proposals to it, even if the static configuration of the ensemble
does not contain it. This seemed to deadlock the ensemble pretty quickly :)
Allow dynamic changes to server cluster membership
think won't be difficult to deal with in the code, but we
have to make sure that this observation is correct.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org
are active followers and E and F are observers then the leader
will propose the new configuration.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse
as the
patch is released.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
Project: Zookeeper
Issue Type
and lot of work, can live with
the kinks in the beginning.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
Project
to assign it to yourself.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
Project: Zookeeper
Issue Type
with conflicting views: A thinks (B, C, D), B
thinks (B, C, D), C thinks (B, C, D), and D thinks (A, B, D), so both A and D
will effectively be out of the ensemble and you can't tolerate any failures.
Allow dynamic changes to server cluster membership
the messages explicitly in the protocol helps to convey the
implemented abstraction, making it easier to read and understand. However, it
is bad for backward compatibility, although it might be the case that we
silently ignore unknown messages.
Allow dynamic changes to server cluster membership
. for point 1) we actually do need to touch the
protocol code a bit to ensure that the setData that changes the view commits in
both the old and new views.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
, if D, E and F have
logged the new view and all the nodes are brought up after a power cycle, a
split brain could still occur, no? Should we allow only one node to be
added/deleted at a time?
Allow dynamic changes to server cluster membership
, still needs to be proven)
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
Project: Zookeeper
Issue Type
, then it will first update it's
configuration to X + 1 when it starts an election and then restart the election.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse
.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
Project: Zookeeper
Issue Type: Improvement
anyway (as you point out), but it would prevent us from doing something
that has no chance of working.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira
for
leader election
I also agree that there is an authentication problem as we don't want some
arbitrary machine trying to join an ensemble.
If you're willing to share your proof sketches, I would be pleased to take a
look at them.
Allow dynamic changes to server cluster membership
[
https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahadev konar updated ZOOKEEPER-107:
Fix Version/s: 3.2.0
Assignee: Patrick Hunt
Allow dynamic changes to server
the wrong jira! :)
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
Project: Zookeeper
Issue Type: Improvement
to vote (it thinks it is permitted to participate), but it won't win any
election since its zxid is too low. A, B, and C will ignore E's votes anyway
because they know that E has been removed from the ensemble.
Allow dynamic changes to server cluster membership
do that in the above case, an election may not be
possible.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
Project
with some deployment errors by tightly tying the data with the
cluster config. the previously mentioned utility would also allow you to avoid
having to start with a single node cluster and growing from there.
Allow dynamic changes to server cluster membership
to point out is that please post a concrete proposal
(since this invloves the core internals of zookeeper) before you start working
on this, so that their is agreement and no wasted effort...
Allow dynamic changes to server cluster membership
and process join requests one-by-one.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
Project: Zookeeper
Issue
if you
have a quorum of followers in both the old and the new configuration. this
seems to be in line with what you are thinking correct?
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL
reasonably
accurate (but this could only affect liveness, not safety, I think).
Please chime in with comments / stuff that I've missed / bugs, otherwise I'll
work on fleshing this out.
Allow dynamic changes to server cluster membership
use DNS for this functionality: make
zookeeper.acme.com resolve to 5 different IP addresses and then specify new
ZooKeeper(zookeeper.acme.com:3233, 1000, this), but DNS is hard to modify. A
replicate webserver would be much easier to update.
Allow dynamic changes to server cluster membership
and each registered plugin would map the host/port mapping
based on the scheme.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
machines to become the masters.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
Project: Zookeeper
Issue
with Hiram that it should be stored persistently at
each replica and changed via the replication protocol.
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https://issues.apache.org/jira
to get a list of zookeeper servers . We
can always update the zookeeper client periodically by fetching from the URI
Allow dynamic changes to server cluster membership
--
Key: ZOOKEEPER-107
URL: https
with the common case of starting up a set of 5 servers forming a new
cluster? Specifically the idea of operations blocking (hiram's comment) until
master is elected. Not sure I see how this works...
Allow dynamic changes to server cluster membership
54 matches
Mail list logo
