aurora-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jing Chen (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (AURORA-1785) Populate curator latches with scheduler information
Date Wed, 12 Oct 2016 08:03:30 GMT

    [ https://issues.apache.org/jira/browse/AURORA-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15567793#comment-15567793
] 

Jing Chen edited comment on AURORA-1785 at 10/12/16 8:02 AM:
-------------------------------------------------------------

Is ServerSet information enough to identify uniquely contender? The information is like:
{noformat}
{"serviceEndpoint":{"host":"aurora.local","port":8081},"additionalEndpoints":{"http":{"host":"aurora.local","port":8081}},"status":"ALIVE"}
{noformat}


was (Author: jingc):
Is ServerSet information enough to identify uniquely contender? The information is like:
{"serviceEndpoint":{"host":"aurora.local","port":8081},"additionalEndpoints":{"http":{"host":"aurora.local","port":8081}},"status":"ALIVE"}

> 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
>
> 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)

Mime
View raw message