Bug 1486293

Summary: [downstream clone - 4.1.6] Frequent traceback on MetadataDiskDescriptionHandler
Product: Red Hat Enterprise Virtualization Manager Reporter: rhev-integ
Component: ovirt-engineAssignee: Idan Shaby <ishaby>
Status: CLOSED ERRATA QA Contact: Kevin Alon Goldblatt <kgoldbla>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.1.4CC: amureini, lsurette, lveyde, ratamir, rbalakri, Rhev-m-bugs, srevivo, tnisan, ykaul, ylavi
Target Milestone: ovirt-4.1.6Keywords: ZStream
Target Release: ---Flags: lsvaty: testing_plan_complete-
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1483401 Environment:
Last Closed: 2017-09-19 07:18:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1483401    
Bug Blocks:    

Description rhev-integ 2017-08-29 11:55:13 UTC
+++ This bug is a downstream clone. The original bug is: +++
+++   bug 1483401 +++

Description of problem:

Engine logs have several of these when attaching Data/Export Domains, when Importing Hosted-Engine Storage Domain etc...

2017-08-21 13:41:45,435+10 WARN  [org.ovirt.engine.core.bll.storage.disk.image.GetUnregisteredDiskQuery] (org.ovirt.thread.pool-6-thread-48) [b56aacc1-c32e-49be-8c67-15897edb9783] Exception while parsing JSON for disk. Exception: '{}': org.codehaus.jackson.JsonParseException: Unexpected character ('g' (code 103)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')
 at [Source: java.io.StringReader@3556c5d1; line: 1, column: 2]
        at org.codehaus.jackson.JsonParser._constructError(JsonParser.java:1433) [jackson-core-asl.jar:1.9.13.redhat-3]
        at org.codehaus.jackson.impl.JsonParserMinimalBase._reportError(JsonParserMinimalBase.java:521) [jackson-core-asl.jar:1.9.13.redhat-3]
        at org.codehaus.jackson.impl.JsonParserMinimalBase._reportUnexpectedChar(JsonParserMinimalBase.java:442) [jackson-core-asl.jar:1.9.13.redhat-3]
        at org.codehaus.jackson.impl.ReaderBasedParser._handleUnexpectedValue(ReaderBasedParser.java:1198) [jackson-core-asl.jar:1.9.13.redhat-3]
        at org.codehaus.jackson.impl.ReaderBasedParser.nextToken(ReaderBasedParser.java:485) [jackson-core-asl.jar:1.9.13.redhat-3]
        at org.codehaus.jackson.map.ObjectMapper._initForReading(ObjectMapper.java:2770) [jackson-mapper-asl.jar:1.9.13.redhat-3]
        at org.codehaus.jackson.map.ObjectMapper._readMapAndClose(ObjectMapper.java:2718) [jackson-mapper-asl.jar:1.9.13.redhat-3]
        at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1877) [jackson-mapper-asl.jar:1.9.13.redhat-3]
        at org.ovirt.engine.core.utils.JsonHelper.jsonToMap(JsonHelper.java:41) [utils.jar:]
        at org.ovirt.engine.core.bll.storage.disk.image.MetadataDiskDescriptionHandler.enrichDiskByJsonDescription(MetadataDiskDescriptionHandler.java:248) [bll.jar:]
        at org.ovirt.engine.core.bll.storage.disk.image.GetUnregisteredDiskQuery.executeQueryCommand(GetUnregisteredDiskQuery.java:105) [bll.jar:]
        at org.ovirt.engine.core.bll.QueriesCommandBase.executeCommand(QueriesCommandBase.java:110) [bll.jar:]
        at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:33) [dal.jar:]
        at org.ovirt.engine.core.bll.executor.DefaultBackendQueryExecutor.execute(DefaultBackendQueryExecutor.java:14) [bll.jar:]
        at org.ovirt.engine.core.bll.Backend.runQueryImpl(Backend.java:582) [bll.jar:]
        at org.ovirt.engine.core.bll.Backend.runInternalQuery(Backend.java:545) [bll.jar:]

It happens when the metadata for the disk is not in json format, like any of these:

DESCRIPTION=Hosted Engine Image
DESCRIPTION=generated by virt-v2v 1.36.5fedora_26,release_1.fc26,libvirt

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Several ways. I think the easiest is to deploy Hosted-Engine and trigger the auto-import. Or do this on an existing env:
1. Create NFS Share
2. Create Export Domain on NFS share
3. Maintenance and Detach Export Domain
4. Use virt-v2v to populate it:
   virt-v2v -o rhev -os rhel7.3
5. Attach Export Domain

Actual results:
Operation succeeds, but logs are polluted with warnings tracebacks that can deviate the user/support from the actual problem.

(Originally by Germano Veit Michel)

Comment 3 rhev-integ 2017-08-29 11:55:24 UTC
Commit e84631956b02ce355e9b0654a6451f6e8ad747be (RHV 4.0) introduced this. Seems like we need to change the logging there to DEBUG, as not having a JSON description is pretty common.

(Originally by Allon Mureinik)

Comment 4 Kevin Alon Goldblatt 2017-09-14 13:06:26 UTC
Verified with the following code:

Verified with the following scenario:
Steps to Reproduce:
Several ways. I think the easiest is to deploy Hosted-Engine and trigger the auto-import. Or do this on an existing env:
1. Create NFS Share
2. Create Export Domain on NFS share
3. Maintenance and Detach Export Domain
4. Change the description to "bla bla bla" in the meta-data file of the export domain
5. Attach the export domain again - the log now displays only the following as expected:
2017-09-14 15:57:29,572+03 WARN  [org.ovirt.engine.core.bll.storage.disk.image.GetUnregisteredDiskQuery] (org.ovirt.thread.pool-6-thread-42) [f1882c1f-af96-4556-8f11-c2ec57c784c2] Could not parse the description (bla bla bli bla blu) of disk ID 'cadd558f-73a0-4ca1-8f1e-dc68343ff7fa'. The description is expected to be in JSON format.

Moving to VERIFIED

Comment 6 errata-xmlrpc 2017-09-19 07:18:50 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Comment 7 Daniel Gur 2019-08-28 12:57:51 UTC

Comment 8 Daniel Gur 2019-08-28 13:03:00 UTC

Comment 9 Daniel Gur 2019-08-28 13:13:07 UTC

Comment 10 Daniel Gur 2019-08-28 13:17:20 UTC