Bug 1550106

Summary: [RFE] IOProcess thread of storage domain should be correlated to the domain id/name
Product: [oVirt] vdsm Reporter: Elad <ebenahar>
Component: RFEsAssignee: shani <sleviim>
Status: CLOSED CURRENTRELEASE QA Contact: Yosi Ben Shimon <ybenshim>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.20.14CC: amureini, bugs, ebenahar, nsoffer, sleviim, ylavi
Target Milestone: ovirt-4.2.3Keywords: EasyFix, FutureFeature
Target Release: ---Flags: rule-engine: ovirt-4.2+
ylavi: exception+
ebenahar: testing_plan_complete-
ylavi: planning_ack+
amureini: devel_ack+
rule-engine: testing_ack+
Hardware: x86_64   
OS: Unspecified   
Whiteboard: logging
Fixed In Version: Doc Type: Enhancement
Doc Text:
Feature: Log IOProcessClient's name Reason: Before this patch, IOProcessesClient name used a counter (e.g. "ioprocess-0") and it was impossible to correlate ioprocess to the storage domain. Result: This patch changes the client name in IOProcessClient to one of the following (as described in the patch): - "Global" - "domain-uuid" - "/[GlusterSD/]server:_path"
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-05-10 06:28:50 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:

Description Elad 2018-02-28 14:06:26 UTC
Description of problem:

Name IOProcess threads according to their storage domains (id/name).

Comment 1 Allon Mureinik 2018-02-28 17:07:32 UTC
Looks like an easy win.

Comment 2 Nir Soffer 2018-02-28 17:16:06 UTC
This is also a candidate for 4.2, the patch should be trivial and easy to backport.

Comment 4 Elad 2018-03-14 14:35:54 UTC
I think something like domain moniter is logged is good:

2018-03-14 16:32:23,918+0200 DEBUG (monitor/d0f5e62) [storage.Monitor] Refreshing domain d0f5e626-3338-4a83-a4be-a8ba7a187d4d (monitor:485)

Where the prefix of the domain id is presented '(monitor/d0f5e62)'

Comment 5 Allon Mureinik 2018-03-27 14:18:10 UTC
Shani, is MODIFIED the right status here? Aren't we waiting for the "fileSD: Log shorter IOProcessClient's name" patch?

Comment 6 shani 2018-03-27 14:58:03 UTC
(In reply to Allon Mureinik from comment #5)
> Shani, is MODIFIED the right status here? Aren't we waiting for the "fileSD:
> Log shorter IOProcessClient's name" patch?

This one has a "related-to" tag, so I thought that this 89084 is enough for verification.
Moved back to "Post" for now.
Thanks for the awareness.

Comment 7 Nir Soffer 2018-04-09 20:40:18 UTC
The vdsm patches show ioprocess client name in most messages, but some ioprocess
logs do not contain the client name, making it hard to correlate the message to
the right client and relevant vdsm code. The additional ioprocess patch fixes this
issue.

Comment 8 shani 2018-04-17 10:10:28 UTC
moving back to 'POST' since it seems that https://gerrit.ovirt.org/#/c/90027/ should be also backported.

Comment 9 shani 2018-04-18 08:15:34 UTC
https://gerrit.ovirt.org/#/c/90027/ is related to ioprocess project.
Moving back to MODIFIED status.

Comment 10 Yosi Ben Shimon 2018-04-22 10:55:34 UTC
Verified using:
vdsm-4.20.25-1.el7ev.x86_64

Actual result:
The IOProcessClient displays the correlated domain.
examples:
2018-04-22 12:12:53,448+0300 INFO  (itmap/2) [IOProcessClient] Starting client /rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Storage__NFS_storage__local__ge16__nfs__0 (__init__:308)

2018-04-22 12:11:52,616+0300 INFO  (itmap/2) [IOProcessClient] Starting client /rhev/data-center/mnt/glusterSD/gluster01.scl.lab.tlv.redhat.com:_storage__local__ge16__volume__2 (__init__:308)

2018-04-22 11:31:10,122+0300 INFO  (monitor/289e3fa) [IOProcessClient] Closing client Global (__init__:583)

2018-04-22 13:49:58,924+0300 INFO  (monitor/ad07bf5) [IOProcessClient] Closing client /rhev/data-cent
er/mnt/vserver-production.qa.lab.tlv.redhat.com:_iso__domain (__init__:583)


Moving to VERIFIED

Comment 11 Sandro Bonazzola 2018-05-10 06:28:50 UTC
This bugzilla is included in oVirt 4.2.3 release, published on May 4th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.3 release, it has been closed with a resolution of CURRENT RELEASE.

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