Bug 1408304
| Summary: | Confusing errors when a volume does not exists in Volume.getInfo | ||
|---|---|---|---|
| Product: | [oVirt] vdsm | Reporter: | Nir Soffer <nsoffer> |
| Component: | Core | Assignee: | Ala Hino <ahino> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Lilach Zitnitski <lzitnits> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.18.0 | CC: | ahino, amureini, bugs, tnisan |
| Target Milestone: | ovirt-4.1.5 | Flags: | rule-engine:
ovirt-4.1+
rule-engine: exception+ |
| Target Release: | 4.19.27 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-23 08:04:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Ala, aren't you working on the same issue for a different BZ? We have BZ 1442688 that is in the same area although it is opened against ovirt-engine. Patches already merged to master, backported and verified on 4.1. As the patches are quite straightforward and with low risk, they are safe to be backported to 4.1.5 -------------------------------------- Tested with the following code: ---------------------------------------- ovirt-engine-4.1.5.2-0.1.el7.noarch vdsm-4.19.27-1.el7ev.x86_64 Tested with the following scenario: Steps to Reproduce: 1. run volume.getInfo on non-existing volume Actual results: INFO message in vdsm.log getVolumeInfo error=Volume does not exist Expected results: Moving to VERIFIED! |
Description of problem: In some flows, we verify that the flow is successful by checking if a volume exists using Volume.getInfo verb. When the volume does not exists (expected), vdsm logs this confusing traceback: 2016-12-22 22:04:06,010 ERROR (jsonrpc/3) [storage.TaskManager.Task] (Task='b34e2474-46d5-4590-81ce-d7644f8419dc') Unexpected error (task:870) Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 877, in _run return fn(*args, **kargs) File "/usr/lib/python2.7/site-packages/vdsm/logUtils.py", line 50, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 3050, in getVolumeInfo volUUID=volUUID).getInfo() File "/usr/share/vdsm/storage/sd.py", line 747, in produceVolume volUUID) File "/usr/share/vdsm/storage/fileVolume.py", line 361, in __init__ manifest = self.manifestClass(repoPath, sdUUID, imgUUID, volUUID) File "/usr/share/vdsm/storage/fileVolume.py", line 61, in __init__ volUUID) File "/usr/share/vdsm/storage/volume.py", line 84, in __init__ self.validate() File "/usr/share/vdsm/storage/volume.py", line 107, in validate self.validateVolumePath() File "/usr/share/vdsm/storage/fileVolume.py", line 120, in validateVolumePath raise se.VolumeDoesNotExist(self.volUUID) VolumeDoesNotExist: Volume does not exist: (u'877f7dd3-fba4-448c-b8e2-2ac44e368c22',) Version-Release number of selected component (if applicable): Any How reproducible: Always Steps to Reproduce: 1. Call Volume.getInfo on non-existing volume Actual results: Confusing exception about expected condition. Expected results: Debug or info log about missing volume. Additional info: When a volume does not exists, getting volume information does should return VolumeDoesNotExist error to engine, but there is no need to log anything special in vdsm. Asking for info about a volume is not an error in vdsm or in the client code. However, if a volume does not exist in some other flow, this is a fatal error that should fail loudly. We cannot handle VolumeDoesNotExist error in a special way and the lower level layer cannot throw another error when a volume does not exits since the lower level layer has no context. One solution is to add an error wrapper that will expose the original error code and message so it can be returned to engine, but the top level error handler in vdsm can detect it and avoid unhelpful logging. A similar problem is client errors - calling with incorrect or missing arguments. In v2v this is handled by ClientError class. This issue exist in other parts of the code, so we need a generic solution that can be applied everywhere in a consistent way.