Bug 837836

Summary: 3.1 - vdsm: Error when trying to login to target ( invalid literal for int() with base 10 )
Product: Red Hat Enterprise Linux 6 Reporter: Oded Ramraz <oramraz>
Component: vdsmAssignee: Yeela Kaplan <ykaplan>
Status: CLOSED ERRATA QA Contact: Gadi Ickowicz <gickowic>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.3CC: abaron, bazulay, cpelland, hateya, iheim, ilvovsky, jbiddle, nlevinki, oourfali, sgrinber, smizrahi, ykaul, zdover
Target Milestone: rcKeywords: Regression, Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: storage
Fixed In Version: vdsm-4.9.6-29.0 Doc Type: Bug Fix
Doc Text:
Previously, creation of iSCSI storage domains caused VDSM to throw an error during the login to target command. This was because the Red Hat Enterprise Virtualization Manager REST API set the portal field to the wrong value. This issue presented only in VDSM-4.9.6-17.0.el6.x86_64. A patch to VDSM removes a conversion to int of the iSCSI portal parameter for two reasons: the parameter is not used in VDSM, and removing this avoids regressions. In new versions, the engine sends 0. Creating iSCSI storage domains no longer causes VDSM to throw errors during the login to target command.
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-04 19:02:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
vdsm logs none

Description Oded Ramraz 2012-07-05 14:15:40 UTC
Description of problem:

When I'm trying to create ISCSI storage domain on rhevm3.0 with vdsm-4.9.6-17.0.el6.x86_64 I'm encountering an error during login to target command . When I'm looking at vdsm logs i see the following error: "ValueError: invalid literal for int() with base 10: 'shafan.eng.lab.tlv.redhat.com' "
Apparently RHEVM Rest API set wrong value to portal field ( same value as storage server )
After downgrading vdsm version on the hosts from vdsm-4.9.6-17.0.el6.x86_64 to vdsm-4.9-113.1.el6.x86_64 the problem disappear. 


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Thread-40::INFO::2012-07-05 00:43:54,964::logUtils::37::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=3, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 'shafan.eng.lab.tlv.redhat.com', 'iqn': 'iqn.2011-10.com.redhat:iscsi-test6', 'portal': 'shafan.eng.lab.tlv.redhat.com', 'user': '', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', 'port': '3260'}], options=None)
Thread-40::ERROR::2012-07-05 00:43:54,964::task::853::TaskManager.Task::(_setError) Task=`b6154a2d-beaa-45be-8415-934d7c6c9cdc`::Unexpected error
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/task.py", line 861, in _run
    return fn(*args, **kargs)
  File "/usr/share/vdsm/logUtils.py", line 38, in wrapper
    res = f(*args, **kwargs)
  File "/usr/share/vdsm/storage/hsm.py", line 1899, in connectStorageServer
    conInfo = _connectionDict2ConnectionInfo(domType, conDef)
  File "/usr/share/vdsm/storage/hsm.py", line 166, in _connectionDict2ConnectionInfo
    tpgt = int(tpgt)
ValueError: invalid literal for int() with base 10: 'shafan.eng.lab.tlv.redhat.com' 


# login command from Rest API: 

2012-07-04 16:27:25,115 - MainThread - storagedomains - DEBUG - Response code is valid: [200, 201] 
2012-07-04 16:27:25,120 - MainThread - storagedomains - DEBUG - Action request content is --  url:http://localhost:8080/api/hosts/fc8d56fa-c5da-11e1-a5b2-001a4a231251/iscsilogin body:<action><async>false</async><grace_period><expiry>10</expiry><absolute>false</absolute></grace_period><iscsi><address>shafan</address><target>iqn.2011-06.com.redhat:ci-iscsi-test</target></iscsi></action> 
2012-07-04 16:27:25,290 - MainThread - storagedomains - DEBUG - Response body for action request is: <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<action>
    <async>false</async>
    <grace_period>
        <expiry>10</expiry>
    </grace_period>
    <iscsi>
        <address>shafan</address>
        <target>iqn.2011-06.com.redhat:ci-iscsi-test</target>
    </iscsi>
    <status>
        <state>failed</state>
    </status>
    <fault>
        <reason>Operation Failed</reason>
        <detail>[]</detail>
    </fault>
</action>

Comment 1 Oded Ramraz 2012-07-05 14:19:39 UTC
Created attachment 596417 [details]
vdsm logs

Comment 5 Saggi Mizrahi 2012-07-16 14:53:26 UTC
This is not a but, someone sent a string in the portal field (which is actually tpgt)

Engine internally never does this and sending this is wrong anyway.

The real issue is that the parameter name has been confusing all this time until I decided to fix it.

This is not a bug, the bug was that it worked in the first place.

Comment 6 Ayal Baron 2012-07-16 16:14:23 UTC
This is still a regression in behaviour and REST API scripts might still fail.
We need to get and ignore this param in vdsm.

Comment 7 Yeela Kaplan 2012-07-24 08:47:40 UTC
http://gerrit.ovirt.org/#/c/6367/

Comment 9 Gadi Ickowicz 2012-08-23 13:52:06 UTC
Verified as working with this xml request:

<test_case>
    <test_name>Create Data Storage Domain iSCSI</test_name>
    <test_action>addStorageDomain</test_action>        <parameters>name='ISCSIDataDomain',type='e{storage_dom_type_data}',storage_type='e{storage_type_iscsi}',host='{vds[0]}',lun='{lun}',lun_address='{lun_address}',lun_target='{lun_target}',lun_port=3260,portal="some_portal"</parameters>
    <positive>TRUE</positive>
</test_case>



using:
rhevm-3.0.7_0001-2.el6_3.x86_64
vdsm-4.9.6-29.0.el6_3.x86_64

Comment 13 errata-xmlrpc 2012-12-04 19:02:07 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.

http://rhn.redhat.com/errata/RHSA-2012-1508.html