[Engine-devel] vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN case

Deepak C Shetty deepakcs at linux.vnet.ibm.com
Mon Mar 18 14:56:59 UTC 2013


I by mistake sent this earlier to users at ovirt
I think the right list is engine-devel, hence resending. Sorry for the 
mispost earlier.


-------- Original Message --------
Subject: 	vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN case
Date: 	Mon, 18 Mar 2013 20:23:57 +0530
From: 	Deepak C Shetty <deepakcs at linux.vnet.ibm.com>
Organization: 	IBM India Pvt. Ltd.
To: 	users at ovirt.org <users at ovirt.org>, Sharad Mishra <snmishra at us.ibm.com>



Hi All,
     I am validating GLUSTERFS Storage domain engine patches (worked on 
by Sharad, in Cc) as posted here...
http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:glusterfs,n,z
against VDSM Glusterfs domain support (already upstream in VDSM)

I see the below issue as part of me creatign a new Gluster Storage 
DOmain in the UI

Engine logs...

2013-03-18 13:27:29,149 INFO 
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] 
(http--0.0.0.0-8700-1) [4b751967] START, 
ConnectStorageServerVDSCommand(HostName = vm-vdsm-de-1, HostId = 
c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId = 
00000000-0000-0000-0000-000000000000, storageType = GLUSTERFS, 
connectionList = [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn: 
null, vfsType: glusterfs, mountOptions: null, nfsVersion: null, 
nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d

VDSM Logs...

Thread-77::INFO::2013-03-18 
13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: 
connectStorageServer(domType=7, 
spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 
'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', 'password': 
'******', 'id': '00000000-0000-0000-0000-000000000000', 'port': ''}], 
options=None)*--> Notice no vfs_type here !!!*

VDSM doesn't recv. the vfs_type in the conList dict !!!

I had this small chat with Saggi of VDSM, just to confirm that there 
isn't a possibility that VDSM might be stripping args that are recd. 
from Engine.. and it doesn't.


---------------------------------------------------------------------------------------------------------------------
<deepakcs> saggi, Hi
<saggi> deepakcs: hi

<deepakcs> saggi, Is it possible that VDSM might strip down some of the 
connparams that are recd. as part of connectStorageServer ?
<deepakcs> saggi, In engine log for GLUSTERFS_DOMAIN i see vfsType being 
passed, but connectStorageServer log doesn't show vfs_type in the params 
dict
<deepakcs> saggi, so wodering where vfs_type is getting dropped in this 
whole process
<saggi> Probably not being sent
<saggi> if it's not being logged
<deepakcs> saggi, engine log has this....
<deepakcs> 2013-03-18 13:27:29,149 INFO 
[org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] 
(http--0.0.0.0-8700-1) [4b751967] START, 
ConnectStorageServerVDSCommand(HostName = vm-vdsm-de-1, HostId = 
c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId = 
00000000-0000-0000-0000-000000000000, storageType = GLUSTERFS, 
connectionList = [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn: 
null, vfsType: glusterfs, mountOptions: null, nfsVersion: nul
<deepakcs> l, nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d
<deepakcs> saggi,  on VDSM side i see this...
<deepakcs> Thread-77::INFO::2013-03-18 
13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: 
connectStorageServer(domType=7, 
spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 
'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', 'password': 
'******', 'id': '00000000-0000-0000-0000-000000000000', 'port': ''}], 
options=None) --> Notice no vfs_type here !!!
<saggi> Then you are not sending the correct connection type

<deepakcs> saggi, 'you' means the engine side of code ? engine patches 
is being done by Sharad, and I amtrying to work with them on this issue

<deepakcs> saggi, domType=7 is GLUSTERFS_DOMAIN, so its correct on that 
front
<saggi> If it show nfsRetrans you are using nfs which doesn't have a 
vfs_type argument
<deepakcs> saggi, but engine log says storageType = GLUSTERFS
<deepakcs> saggi, maybe i can send mail to users at ovirt list to see if 
anybody can provide more clues
<deepakcs> saggi, but definitely this doesn't looks like a vdsm side of 
issue rite ?
<saggi> We log the params as we get them

<deepakcs> saggi, right, thats what i also see.. just wanted to confirm 
once with you, before i sent mail to ovirt folks

---------------------------------------------------------------------------------------------------------------------


Can someone help provide any clues on what might be the issue here ?
Because VDSM doesn't see vfs_type, the connectStorageServer fails and 
hence new SD cannot be created !

thanx,
deepak




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20130318/6a963c0d/attachment-0001.html>


More information about the Devel mailing list