question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Monitor-failures information is missing in PyEZ facts

See original GitHub issue

I am came here from Juniper/ansible-junos-stdlib#482 because, AFAIK, ansible-junos-stdlib is using py-junos-eznc as the upstream project.

So, my question is, how to get Monitor-failures information in PyEZ facts, is it supported at all?

It’s exists in CLI output:

> show chassis cluster status                       
Monitor Failure codes:
    CS  Cold Sync monitoring        FL  Fabric Connection monitoring
    GR  GRES monitoring             HW  Hardware monitoring
    IF  Interface monitoring        IP  IP monitoring
    LB  Loopback monitoring         MB  Mbuf monitoring
    NH  Nexthop monitoring          NP  NPC monitoring
    SP  SPU monitoring              SM  Schedule monitoring
    CF  Config Sync monitoring      RE  Relinquish monitoring

Cluster ID: 1
Node   Priority Status         Preempt Manual   Monitor-failures

Redundancy group: 0 , Failover count: 1
node0  100      secondary      no      no       None
node1  200      primary        no      no       None

But seems it’s missing at https://github.com/Juniper/py-junos-eznc/blob/master/lib/jnpr/junos/facts/get_chassis_cluster_status.py

So, I am curious if it’s possible to add such fact?

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Comments:7 (4 by maintainers)

github_iconTop GitHub Comments

1reaction
EpiqStycommented, Mar 23, 2020

Well, the actual question is if the device.rpc.get_chassis_cluster_status contains such information of not. In case if it’s already exists in RPC output, I see no real increase of time. In case if it’s not exists there, maybe I could ask upstream developers to add it. Thanks for your time anyway

1reaction
vnitinvcommented, Mar 23, 2020

@EpiqSty Discussed this with the team. Adding many other facts will make facts gathering more time consuming (which it already is). We only wanted to keep facts which are common in nature and often to be used. User-specific data can be fetched using RPC/CLI calls. Let me know if you have a different opinion.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Use Junos PyEZ to Retrieve Facts from Junos Devices
The device facts are accessed as the facts attribute of the Device object. For detailed information about the keys that are included in...
Read more >
4. Junos PyEZ - Automating Junos Administration [Book]
PyEZ refers to this basic information as facts, and the information is accessible via the device instance's facts dictionary attribute.
Read more >
jnpr.junos.facts — Junos PyEZ 2.1.0 documentation
A dictionary-like object of read-only facts about the Junos device. ... See the RE_master fact for info on the 'master' RE of each...
Read more >
Using the Juniper PyEZ Library [Beginner] - dave.dev
You'll notice when it's not present, output from something (a function, ... Check the PyEZ documentation for more info if you want more ......
Read more >
Using the Juniper/PyEZ Container and the jnpr.junos.facts ...
The Using the Juniper/ PyEZ Container and the jnpr.junos. facts Library learning byte shows users how to use the the Juniper/ PyEZ Docker ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found