[INFRAUTILS-31] diagstatus including cause of failures Created: 20/Mar/18  Updated: 15/May/18  Resolved: 15/May/18

Status: Resolved
Project: infrautils
Component/s: diagstatus
Affects Version/s: None
Fix Version/s: Fluorine

Type: Improvement Priority: Medium
Reporter: Michael Vorburger Assignee: Jamo Luhrsen
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by INFRAUTILS-36 showSvcStatus: Status retrieval JMX O... Resolved
Relates
relates to OPNFLWPLUG-988 Openflow Service ERROR state in Fluorine Verified

 Description   

from https://lists.opendaylight.org/pipermail/infrautils-dev/2018-March/000635.html and related to OPNFLWPLUG-988:

seeing this gives me an idea for an Enhancement, in the infrautils diagstatus code: What I think one would ideally want to see in this output, both on the CLI as well as when used e.g. from a CSIT script via JMX, to avoid having to dig through logs, is WHY something is in Error... so ideally, it should probably be possible to DiagStatusService report() not just a ServiceState in a ServiceDescriptor, but a Throwable to diagstatus, which would set the status to ERROR - and then the CLI/JMX/etc. could include that Throwable as more detailed background about the failure. The code catching exceptions and setting an ERROR ServiceState would then pass that Throwable to the ServiceDescriptor. In this particular case, the NPE that was apparently fixed by c/69657 would then show up there - which would probably help, in the future, to see the real problem more immediately.

 Comments   
Comment by Michael Vorburger [ 20/Mar/18 ]

There are at least 2 parts - minor extension in infrautils itself, and then using that in opflowplugin, genius, netvirt...

For infrautils the starting point would literally be to add a Throwable cause to org.opendaylight.infrautils.diagstatus.ServiceDescriptor. Then use that in DiagStatusServiceMBeanImpl, where it puts together what you see in showSvcStatus and by JMX via Jolokia.

Then grep for where other create a new ServiceDescriptor(...), whenever it actually caught any exception (catch Throwable { }) then pass that as cause.

Comment by Faseela K [ 21/Mar/18 ]

This looks like a good idea..I think I can work on it..

Comment by Michael Vorburger [ 21/Mar/18 ]

> This looks like a good idea..I think I can work on it..

k.faseela note jluhrsen self-assigned this to himself to have a go at it, so let him, or just make sure you two sync!

Comment by Faseela K [ 21/Mar/18 ]

That's great then! Would let jluhrsen work on the same.. 

Comment by Jamo Luhrsen [ 25/Mar/18 ]

starting to poke around... Not sure on any timetable yet.

Comment by Michael Vorburger [ 03/Apr/18 ]

https://git.opendaylight.org/gerrit/#/c/70220/

Comment by Michael Vorburger [ 16/Apr/18 ]

Thought about this again while thinking about INFRAUTILS-33 .. so when this is implemented, we should add that new getErrorCause() to the acquireServiceStatusAsJSON in the DiagStatusServiceMBeanImpl so that the INFRAUTILS-33 will report that as well, and not just the CLI which goes through acquireServiceStatusDetailed() where c/70220/1 adds it.

Comment by Michael Vorburger [ 14/May/18 ]

jluhrsen OK to close this JIRA issue now that c/70220 is merged, or wanna keep it open?

Generated at Wed Feb 07 20:02:05 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.