Bug 1405770 - Improve documentation on adding direct LUNs via the API
Summary: Improve documentation on adding direct LUNs via the API
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RestAPI
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ovirt-4.1.1
: ---
Assignee: shani
QA Contact: Elad
URL:
Whiteboard:
Depends On: 1275649
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-18 09:51 UTC by Allon Mureinik
Modified: 2017-04-21 09:40 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of: 1404389
Environment:
Last Closed: 2017-04-21 09:40:20 UTC
oVirt Team: Storage
Embargoed:
amureini: needinfo+
amureini: needinfo+
rule-engine: ovirt-4.1+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 70096 0 master MERGED Improving DisksService::Add Documentation 2017-01-22 11:03:45 UTC
oVirt gerrit 70958 0 model_4.1 MERGED Improving DisksService::Add Documentation 2017-01-22 11:04:05 UTC
oVirt gerrit 70959 0 model_4.0 MERGED Improving DisksService::Add Documentation 2017-01-22 11:04:27 UTC
oVirt gerrit 71314 0 ovirt-engine-4.1 MERGED restapi: Update to model 4.1.29 2017-01-29 09:50:26 UTC

Description Allon Mureinik 2016-12-18 09:51:46 UTC
When adding a Direct LUN via the API, there are two flavors that can be used:
1. With a HOST element. In this case, the host is used for sanity checks (e.g., that the LUN is visible) and to retrieve basic information about the LUN (e.g., size)
2. Without a HOST element. In this case, the operation is a database-only operation, and the storage is never accessed.

While this is the intended behavior, it is not intuitive, and the documentation in DisksService#Add should be improved to explain this.

An example of how this behavior is non intuitive can be seen in Bug #1404389:

+++ This bug was initially created as a clone of Bug #1404389 +++

Description of problem:
When adding a 50 GB direct lun to the system via REST API, it shows it's size is < 1 GB.
The POST body to /api/disks is:
<disk>
    <alias>direct_lun_test</alias>
    <lun_storage>
        <logical_units>
            <logical_unit id="LUN_ID">
                <address>ISCSI_SERVER_IP</address>
                <port>3260</port>
                <target>LUN_TARGET</target>
            </logical_unit>
        </logical_units>
        <type>iscsi</type>
    </lun_storage>
</disk>



Version-Release number of selected component (if applicable):
4.1.0-0.2.master.20161212071212.git8a015dd.el7.centos

How reproducible:
Add direct

Steps to Reproduce:
1. Send POST request to /api/disks with body:
<disk>
    <alias>direct_lun_test</alias>
    <lun_storage>
        <logical_units>
            <logical_unit id="LUN_ID">
                <address>ISCSI_SERVER_IP</address>
                <port>3260</port>
                <target>LUN_TARGET</target>
            </logical_unit>
        </logical_units>
        <type>iscsi</type>
    </lun_storage>
</disk>
2. Check the disk's size
3.

Actual results:


Expected results:


Additional info:

--- Additional comment from Allon Mureinik on 2016-12-14 00:52:11 IST ---

Without a host parameter, this just adds a LUN to the database. It should be refreshed when you try to use it.

Can you please try with the host element and check if it gets the size registered?

--- Additional comment from Raz Tamir on 2016-12-14 01:39:54 IST ---

Allon,
When adding the host it does show the correct LUN size.
When adding it without the host attribute and attach it to VM, the size isn't refreshed and the VM see it's real size (# lsblk)

--- Additional comment from Allon Mureinik on 2016-12-15 15:56:53 IST ---

OK, I think there are two issues here:

(In reply to Raz Tamir from comment #2)
> Allon,
> When adding the host it does show the correct LUN size.
Good news.
As I noted in comment 1, when a <host> element is not provided, this is just a DB operation, and no details from the LUN itself are saved to the DB.
This is the intended behavior, although I agree this is not necessarily intuitive, and should be documented better. 
Juan - I guess that DisksService#Add is the right place to document it?

> When adding it without the host attribute and attach it to VM, the size
> isn't refreshed and the VM see it's real size (# lsblk)
After going over the code again, this indeed is not the behavior. We need some way to refresh the LUNs details, which, AFAIK, we don't have.
I think we should open a new bug (RFE?) on this, and prioritize it with PM.

--- Additional comment from Idan Shaby on 2016-12-15 16:05:33 IST ---

This seems to be like a dup of bug 1275649 which I solved more than a year ago.

Regarding a scenario where you add a direct lun without a host - Allon I think we talked about it a while ago and I raised the idea that we can call GetDeviceList with a random host in the vm's dc when we attach the direct lun to that vm.

If we agree on the idea, this should indeed be a new RFE, IMHO.

--- Additional comment from Juan Hernández on 2016-12-15 17:02:51 IST ---

(In reply to Allon Mureinik from comment #3)
> Juan - I guess that DisksService#Add is the right place to document it?

Yes, that is the right place.

--- Additional comment from Allon Mureinik on 2016-12-18 11:43:28 IST ---

(In reply to Idan Shaby from comment #4)
> This seems to be like a dup of bug 1275649 which I solved more than a year
> ago.
Seems so, yes, but let's keep this BZ for future work described in comment 3.

> 
> Regarding a scenario where you add a direct lun without a host - Allon I
> think we talked about it a while ago and I raised the idea that we can call
> GetDeviceList with a random host in the vm's dc when we attach the direct
> lun to that vm.
> 
> If we agree on the idea, this should indeed be a new RFE, IMHO.
Not sure if attaching is the right event to trigger this (need PM input here).
But as this was always the behavior, and I don't see any critical flow blocked by NOT having this new capability, I agree we should treat this as an RFE.
Raz/Yaniv - if you disagree, please weigh in here.

Comment 1 Yaniv Kaul 2016-12-25 09:18:34 UTC
If you are already into this, I'd appreciate if you can also give an example of creating one against multiple IPs - do you have to use multiple logical_unit objects with different ISCSI_SERVER_IP , etc.

Comment 2 Elad 2017-02-02 09:30:50 UTC
rhevm-4.1.0.3-0.1.el7.noarch

The explanation why the disk size is reported wrongly is not documented in the response body, I this it should be.


Add direct LUN request:


<disk>
    <alias>direct_lun_test</alias>
    <lun_storage>
        <logical_units>
            <logical_unit id="3514f0c5a516008d7">
                <address>10.35.146.129</address>
                <address>10.35.146.163</address>
                <address>10.35.146.193</address>
                <address>10.35.146.225</address>
                <port>3260</port>
                <target>iqn.2008-05.com.xtremio:xio00153500071-514f0c50023f6c00</target>
            </logical_unit>
        </logical_units>
        <type>iscsi</type>
    </lun_storage>
</disk>


===============================================================

Add direct LUN response:


<disk href= "/ovirt-engine/api/disks/7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f" id="7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f">
<actions>
<link href= "/ovirt-engine/api/disks/7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f/export" rel="export"/>
<link href= "/ovirt-engine/api/disks/7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f/move" rel="move"/>
<link href= "/ovirt-engine/api/disks/7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f/sparsify" rel="sparsify"/>
<link href= "/ovirt-engine/api/disks/7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f/copy" rel="copy"/>
</actions>
<name>direct_lun_test</name>
<link href= "/ovirt-engine/api/disks/7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f/permissions" rel="permissions"/>
<link href= "/ovirt-engine/api/disks/7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f/statistics" rel="statistics"/>
<alias>direct_lun_test</alias>
<lun_storage id="3514f0c5a516008d7">
<logical_units>
<logical_unit id="3514f0c5a516008d7">
<disk_id>7bb21c2d-9c68-4c28-8afa-1fb0e58cc86f</disk_id>
<paths>0</paths>
<size>0</size>
</logical_unit>
</logical_units>
</lun_storage>
<propagate_errors>false</propagate_errors>
<shareable>false</shareable>
<storage_type>lun</storage_type>
<wipe_after_delete>false</wipe_after_delete>
</disk>

Comment 3 Elad 2017-02-07 16:11:15 UTC
model doesn't include the fix for the bug. Please verify with CI it is in the latest build.

Comment 4 Allon Mureinik 2017-02-08 09:41:03 UTC
This bug was accidently moved to ON_QA, and this build indeed does not include the fix. It is, however, merged to the correct branch, so the next build should include it.
Pushing out to be verified when the build is available.

Comment 5 Elad 2017-02-19 12:04:34 UTC
The model now includes the right information regarding adding  direct LUN:

Adding a new direct LUN disk:

When adding a new floating direct LUN via the API, there are two flavors that can be used:

With a host element - in this case, the host is used for sanity checks (e.g., that the LUN is visible) and to retrieve basic information about the LUN (e.g., size and serial).

Without a host element - in this case, the operation is a database-only operation, and the storage is never accessed.


============
Used:
rhevm-4.1.1.2-0.1.el7.noarch
ovirt-engine-restapi-4.1.1.2-0.1.el7.noarch


Note You need to log in before you can comment on or make changes to this bug.