Bug 1768707

Summary: Cannot set or update iscsi portal group tag when editing storage connection via API
Product: Red Hat Enterprise Virtualization Manager Reporter: Germano Veit Michel <gveitmic>
Component: ovirt-engineAssignee: Ahmad Khiet <akhiet>
Status: CLOSED ERRATA QA Contact: Evelina Shames <eshames>
Severity: low Docs Contact:
Priority: medium    
Version: 4.3.6CC: akhiet, loberman, mkalinin, pelauter, rdlugyhe, tnisan
Target Milestone: ovirt-4.4.0Flags: lsvaty: testing_plan_complete-
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-08-04 13:20:56 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 Germano Veit Michel 2019-11-05 04:05:10 UTC 
Description of problem:

When specifying portal (portal target group tag) of an iSCSI Storage Connection via REST API, the engine seems to ignore it and always sets to 1, both on creation and update of existing connection.

https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html-single/rest_api_guide/index#types-storage_connection

Version-Release number of selected component (if applicable):
ovirt-engine-4.3.6.6-1.el7.noarch

How reproducible:
Always

Steps to Reproduce:
1. Define a connection, specifying portal:
# cat connection1.xml 
<storage_connection>
  <address>192.168.153.252</address>
  <port>3260</port>
  <target>iqn.2003-01.org.linux-iscsi.storage.x8664:sn.f39f33014c8b</target>
  <type>iscsi</type>
  <portal>2460</portal>
</storage_connection>

2. Create the connection, the output returned is already missing it:

$ curl -X POST -H "Accept: application/xml" -H "Content-type: application/xml" -u admin@internal:redhat --cacert /etc/pki/ovirt-engine/ca.pem -T connection1.xml https://engine.kvm/ovirt-engine/api/storageconnections

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<storage_connection href="/ovirt-engine/api/storageconnections/fa3a9818-cdf0-46f4-b61c-1a7c5f49fc4f" id="fa3a9818-cdf0-46f4-b61c-1a7c5f49fc4f">
    <address>192.168.153.252</address>
    <port>3260</port>
    <target>iqn.2003-01.org.linux-iscsi.storage.x8664:sn.f39f33014c8b</target>
    <type>iscsi</type>
</storage_connection>

3. Portal is set to 1. Check the DB:

# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -c "select id,portal from storage_server_connections"
                  id                  | portal 
--------------------------------------+--------
 132f9a8f-d062-4d02-b6a2-706dccd6d6be | 2460
 b0aaac7f-3ad2-47cf-ae56-ebcc3afff849 | 1
 f823f38b-1612-4bd1-bc07-35573c67d73d | 1
 fa3a9818-cdf0-46f4-b61c-1a7c5f49fc4f | 1          <-----------
 620e097d-63d7-45be-8be2-2baa5462abf0 | 1
(5 rows)

Actual results:
tag always set to 1?

Expected results:
tag set as specified
Comment 2 Marina Kalinin 2019-11-11 18:38:36 UTC 
What is portal group tag?
https://library.netapp.com/ecmdocs/ECMP1196995/html/GUID-1F88AA34-5C39-495A-88FB-0ACAB3CB7EB3.html
https://library.netapp.com/ecmdocs/ECMP1196995/html/GUID-E12CCC64-FD0A-4A02-8C21-8958DC9E0AFC.html

It identifies a portal group within an iSCSI node. All network portals with the same portal group tag in the context of a given iSCSI node are in the same portal group.
Comment 3 Marina Kalinin 2019-11-22 21:32:26 UTC 
I was trying to understand if the portal group matters at all for the connection. For my understanding, it is not required to specify it during connection, so RHV does not specify it. But if the customer does specify it on setup, maybe it matters to them/their storage to have it in future connects as well.

IMO, we should test this and see how it works on connect, if we have different than 1 portal group tag set on the storage side. If it can connect without a problem without specifying it, probably this bug does not matter. Otherwise we should fix it.
Comment 4 RHV bug bot 2019-12-13 13:13:10 UTC 
WARN: Bug status (ON_QA) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops: Bug status (ON_QA) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops
Comment 5 RHV bug bot 2019-12-20 17:43:15 UTC 
WARN: Bug status (ON_QA) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops: Bug status (ON_QA) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops
Comment 6 Evelina Shames 2020-01-02 08:10:32 UTC 
Verified on engine-4.4.0-0.13.master.el7
Comment 7 RHV bug bot 2020-01-08 14:48:05 UTC 
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops
Comment 8 RHV bug bot 2020-01-08 15:13:48 UTC 
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops
Comment 9 RHV bug bot 2020-01-24 19:49:50 UTC 
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops
Comment 19 errata-xmlrpc 2020-08-04 13:20:56 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 (Important: RHV Manager (ovirt-engine) 4.4 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

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

https://access.redhat.com/errata/RHSA-2020:3247