New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Fix Comware Processor Discovery && Hardware Info #7206

Merged
merged 2 commits into from Sep 1, 2017

Conversation

Projects
None yet
4 participants
@Rosiak
Contributor

Rosiak commented Aug 22, 2017

DO NOT DELETE THIS TEXT

Please note

Please read this information carefully. You can run ./scripts/pre-commit.php to check your code before submitting.

Testers

If you would like to test this pull request then please run: ./scripts/github-apply <pr_id>, i.e ./scripts/github-apply 5926

Tested on MSR, VSR, 5800, 5900, 5940, 10500.

Processor:
Discovery broke if processor usage at discovery point was 0, hence we could risk having the processor added/removed during each run on devices with no load. Secondly, we can't rely on the class "module" as other entities are also branded as this hence adding bogus processors. This will not break graphs as we continue to use the same indexes. I have changed the descr as we should just present what HPE publish, even if the devices is IRF'ed(this now matches the descr in mempools).

Hardware:
The current MIB available doesn't support the newer models, also the model number listed in the sysDescr is a much better representation.


This change is Reviewable

@scrutinizer-notifier

This comment has been minimized.

Show comment
Hide comment
@scrutinizer-notifier

scrutinizer-notifier Aug 22, 2017

The inspection completed: No new issues

scrutinizer-notifier commented Aug 22, 2017

The inspection completed: No new issues

@kkrumm1

This comment has been minimized.

Show comment
Hide comment
@kkrumm1

kkrumm1 Aug 22, 2017

Member

need any testers?

Member

kkrumm1 commented Aug 22, 2017

need any testers?

@Rosiak

This comment has been minimized.

Show comment
Hide comment
@Rosiak

Rosiak Aug 22, 2017

Contributor

@kkrumm1 Sure, would be great :)

Contributor

Rosiak commented Aug 22, 2017

@kkrumm1 Sure, would be great :)

@laf

This comment has been minimized.

Show comment
Hide comment
@laf

laf Aug 23, 2017

Member

@kkrumm1 let me know when you've tested so we can merge.

Member

laf commented Aug 23, 2017

@kkrumm1 let me know when you've tested so we can merge.

@kkrumm1

This comment has been minimized.

Show comment
Hide comment
@kkrumm1

kkrumm1 Aug 24, 2017

Member

I tested it and on HPE Comware Switch model 1910 and the CPU used to show but now its not discovering it.
On the HPE Comware 10508 model, the CPU is showing but the name is "virtue Board"

discovery output 1910: https://gist.github.com/kkrumm1/6714b821f24f796f721771a70072fd6b
discovery output 10508: https://gist.github.com/kkrumm1/72cdd77978e4d7d0274bdffad56ea481

Member

kkrumm1 commented Aug 24, 2017

I tested it and on HPE Comware Switch model 1910 and the CPU used to show but now its not discovering it.
On the HPE Comware 10508 model, the CPU is showing but the name is "virtue Board"

discovery output 1910: https://gist.github.com/kkrumm1/6714b821f24f796f721771a70072fd6b
discovery output 10508: https://gist.github.com/kkrumm1/72cdd77978e4d7d0274bdffad56ea481

@Rosiak

This comment has been minimized.

Show comment
Hide comment
@Rosiak

Rosiak Aug 24, 2017

Contributor

Just a few quick thoughts:

As for the 1910 I'm not quite sure how to fix that since it seems that I cannot match on the entPhysicalName. I would have to match Level 1 Virtual Module #1, but what makes Level 2 Virtual Module #0 invalid in this case?

For the 10508 we are now just using the what's provided by HPE, even though this might be a bit crappy in some cases :(

Contributor

Rosiak commented Aug 24, 2017

Just a few quick thoughts:

As for the 1910 I'm not quite sure how to fix that since it seems that I cannot match on the entPhysicalName. I would have to match Level 1 Virtual Module #1, but what makes Level 2 Virtual Module #0 invalid in this case?

For the 10508 we are now just using the what's provided by HPE, even though this might be a bit crappy in some cases :(

@kkrumm1

This comment has been minimized.

Show comment
Hide comment
@kkrumm1

kkrumm1 Aug 24, 2017

Member

Okay, no worries on the 1910's they are junk switches. :)

Member

kkrumm1 commented Aug 24, 2017

Okay, no worries on the 1910's they are junk switches. :)

@laf laf merged commit 21283f4 into librenms:master Sep 1, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
license/cla Contributor License Agreement is signed.
Details
@lock

This comment has been minimized.

Show comment
Hide comment
@lock

lock bot May 17, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed.

lock bot commented May 17, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed.

@lock lock bot locked as resolved and limited conversation to collaborators May 17, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.