Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id C8F58200BC2 for ; Wed, 2 Nov 2016 17:15:00 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id C7A39160AF0; Wed, 2 Nov 2016 16:15:00 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 1F778160AFB for ; Wed, 2 Nov 2016 17:14:59 +0100 (CET) Received: (qmail 11990 invoked by uid 500); 2 Nov 2016 16:14:59 -0000 Mailing-List: contact issues-help@aurora.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@aurora.apache.org Delivered-To: mailing list issues@aurora.apache.org Received: (qmail 11815 invoked by uid 99); 2 Nov 2016 16:14:58 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Nov 2016 16:14:58 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id D0FB82C2A66 for ; Wed, 2 Nov 2016 16:14:58 +0000 (UTC) Date: Wed, 2 Nov 2016 16:14:58 +0000 (UTC) From: "Stephan Erb (JIRA)" To: issues@aurora.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (AURORA-1785) Populate curator latches with scheduler information MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Wed, 02 Nov 2016 16:15:00 -0000 [ https://issues.apache.org/jira/browse/AURORA-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Erb updated AURORA-1785: -------------------------------- Fix Version/s: 0.17.0 > Populate curator latches with scheduler information > --------------------------------------------------- > > Key: AURORA-1785 > URL: https://issues.apache.org/jira/browse/AURORA-1785 > Project: Aurora > Issue Type: Task > Reporter: Zameer Manji > Assignee: Jing Chen > Priority: Minor > Labels: newbie > Fix For: 0.17.0 > > > If you look at the mesos ZK node for leader election you see something like this: > {noformat} > u'json.info_0000000104', > u'json.info_0000000102', > u'json.info_0000000101', > u'json.info_0000000098', > u'json.info_0000000097' > {noformat} > Each of these nodes contains data about the machine contending for leadership. It is a JSON serialized {{MasterInfo}} protobuf. This means an operator can inspect who is contending for leadership by checking the content of the nodes. > When you check the aurora ZK node you see something like this: > {noformat} > u'_c_2884a0d3-b5b0-4445-b8d6-b271a6df6220-latch-0000000774', > u'_c_86a21335-c5a2-4bcb-b471-4ce128b67616-latch-0000000776', > u'_c_a4f8b0f7-d063-4df2-958b-7b3e6f666a95-latch-0000000775', > u'_c_120cd9da-3bc1-495b-b02f-2142fb22c0a0-latch-0000000784', > u'_c_46547c31-c5c2-4fb1-8a53-237e3cb0292f-latch-0000000780', > u'member_0000000781' > {noformat} > Only the leader node contains information. The curator latches contain no information. It is not possible to figure out which machines are contending for leadership purely from ZK. > I think we should attach data to the latches like mesos. > Being able to do this is invaluable to debug issues if an extra master is added to the cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)