Return-Path: X-Original-To: apmail-curator-user-archive@minotaur.apache.org Delivered-To: apmail-curator-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 68AB111F1F for ; Wed, 21 May 2014 17:34:57 +0000 (UTC) Received: (qmail 77497 invoked by uid 500); 21 May 2014 17:34:57 -0000 Delivered-To: apmail-curator-user-archive@curator.apache.org Received: (qmail 77450 invoked by uid 500); 21 May 2014 17:34:57 -0000 Mailing-List: contact user-help@curator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@curator.apache.org Delivered-To: mailing list user@curator.apache.org Received: (qmail 77442 invoked by uid 99); 21 May 2014 17:34:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 May 2014 17:34:57 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of cjnolet@gmail.com designates 209.85.223.174 as permitted sender) Received: from [209.85.223.174] (HELO mail-ie0-f174.google.com) (209.85.223.174) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 May 2014 17:34:53 +0000 Received: by mail-ie0-f174.google.com with SMTP id lx4so2326223iec.33 for ; Wed, 21 May 2014 10:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jgW7auXJNW+/V+YW0ugbQ8zLPdvyQDDAdsuPgYXcGdU=; b=U1kGWiLNPKjMAyOGwRQjsSYVz7k2W+5qnGywN1O8MdUPyldrRsaOTmfr6qmfLJxNN2 v2BercIPg2QdHHtR3fbA9y6UnRLPHMmQsm7de1gXgAZBb0D+G0dmW4wq6/LIu3aLS/CM h7BCThRBiPWuz78XiG4PcSxfCb+8XOqn8EoP8U6M7SIZnz/3t9/V2ZvuIKmJiX5ex13q xNTdapA4MlEZBk2s56084bYOlKyfflnh0T8zaoyqLzMFu8BhtSBeXmcDNc7xJACR/lF+ KVvT8gBTABCHIdU3W3RgBYQEcU25SJgN/yTeBU6+rAv7aP4BnggikBvAx/8cdigUVicb ILkA== MIME-Version: 1.0 X-Received: by 10.42.68.18 with SMTP id v18mr48210202ici.1.1400693672806; Wed, 21 May 2014 10:34:32 -0700 (PDT) Received: by 10.64.11.133 with HTTP; Wed, 21 May 2014 10:34:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 13:34:32 -0400 Message-ID: Subject: Re: Force leader From: Corey Nolet To: Jordan Zimmerman Cc: user Content-Type: multipart/alternative; boundary=20cf303636d9ce8f4e04f9ec6830 X-Virus-Checked: Checked by ClamAV on apache.org --20cf303636d9ce8f4e04f9ec6830 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It it helps, here's a rough design of the project: https://github.com/calrissian/conductor On Wed, May 21, 2014 at 1:33 PM, Corey Nolet wrote: > Jordan, > > Thanks for your quick response! So what I am building is a faul-tolerant > framework for linux systems to watch over some number of processes and, > when a process goes down and can't be brought back up (disk space, memory= , > etc...), I want the process watcher to revoke its leadership so that a > different machine can start up the process, do any configuration necessar= y > to route clients over to that machine, and assume responsibility as the > lead for that process. > > Often times what happens is a couple physical machines go down and ALL th= e > managed processes end up on a single machine. > > I'm giving the users control over groups of processes. A group would be > "amqp broker" or "web server". Once a sys admin comes into work and > realizes what happened, they are going to want to force the amqp broker > back to a specific node and force the web server onto some other node. Th= e > way I've designed it, this means those nodes need to be forced to be the > leaders for those groups. > > Thanks again! > > > On Wed, May 21, 2014 at 1:20 PM, Jordan Zimmerman < > jordan@jordanzimmerman.com> wrote: > >> I=E2=80=99d need more details to answer concretely. But, this sounds lik= e a >> simple lock. Have the process that wants to be leader acquire an >> InterProcessMutex. >> >> -JZ >> >> >> From: Corey Nolet cjnolet@gmail.com >> Reply: user@curator.apache.org user@curator.apache.org >> Date: May 21, 2014 at 12:12:35 PM >> To: user user@curator.apache.org >> Subject: Force leader >> >> I have a cluster which is electing a single leader to perform >> operations on a node until the node is deemed to be unhealthy. At this >> time, the leader revokes itself and another leader is elected to perform >> the operations. >> >> There are times, however, when I need the ability to force a specific >> leader. How would I implement something like this? I really don't want t= o >> have to cascade through all the other nodes and tell them to revoke thei= r >> leadership because they will each try to run some initialization upon >> becoming the leader and that would waste resources. >> >> Any ideas? >> >> Thanks! >> >> > --20cf303636d9ce8f4e04f9ec6830 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It it helps, here's a rough design of the project:


On Wed, May 21, 2014 at 1:33 PM, Corey N= olet <cjnolet@gmail.com> wrote:
Jordan,

Thanks for your quick response!= So what I am building is a faul-tolerant framework for linux systems to wa= tch over some number of processes and, when a process goes down and can'= ;t be brought back up (disk space, memory, etc...), I want the process watc= her to revoke its leadership so that a different machine can start up the p= rocess, do any configuration necessary to route clients over to that machin= e, and assume responsibility as the lead for that process.=C2=A0

Often times what happens is a couple physical machines = go down and ALL the managed processes end up on a single machine.=C2=A0

I'm giving the users control over groups of proce= sses. A group would be "amqp broker" or "web server". O= nce a sys admin comes into work and realizes what happened, they are going = to want to force the amqp broker back to a specific node and force the web = server onto some other node. The way I've designed it, this means those= nodes need to be forced to be the leaders for those groups.=C2=A0

Thanks again!


On = Wed, May 21, 2014 at 1:20 PM, Jordan Zimmerman <jordan@jordanzimm= erman.com> wrote:
I=E2=80=99d need more details to answer concretely. But, this sounds like a= simple lock. Have the process that wants to be leader acquire an InterProc= essMutex.

-JZ


From:=C2=A0Corey Nolet cjnolet@gmail.com
Reply:= =C2=A0user@curator.apache.org user@curator.apache.org
Date:=C2=A0May 21, 2014 at 12:12:35 PMTo:=C2=A0user user@curator.apache.org
Subject= :=C2=A0 Force leader

I have a cluster which is electing a single leader to perform operations on a node until the node is deemed to be unhealthy. At this time, the leader revokes itself and another leader is elected to perform the operations.

There are times, however, when I need the ability to force a specific leader. How would I implement something like this? I really don't want to have to cascade through all the other nodes and tell them to revoke their leadership because they will each try to run some initialization upon becoming the leader and that would waste resources.

Any ideas?

Thanks!


--20cf303636d9ce8f4e04f9ec6830--