[
https://issues.apache.org/jira/browse/AURORA-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zameer Manji updated AURORA-1785:
---------------------------------
Description:
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.
was:
(Assigning this to John, who is our curator expert for triage/feasibility)
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.
> 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
> 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)
