Bug 866580 - [engine]Able to add directLUN disk through REST API with incorrect parameters
[engine]Able to add directLUN disk through REST API with incorrect parameters
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.1.0
All Linux
unspecified Severity high
: ---
: 3.2.0
Assigned To: Liron Aravot
Gadi Ickowicz
storage
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-15 12:26 EDT by Gadi Ickowicz
Modified: 2016-02-10 12:09 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-14 22:22:23 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
engine logs (2.97 MB, text/x-log)
2012-10-15 12:26 EDT, Gadi Ickowicz
no flags Details

  None (edit)
Description Gadi Ickowicz 2012-10-15 12:26:25 EDT
Created attachment 627552 [details]
engine logs

Description of problem:
I was able to create a directLUN disk with parameters pointing to a false server and invalid LUN.

This was created through RESTAPI, and then was created and appeared in the GUI as well.

Version-Release number of selected component (if applicable):
rhevm-3.1.0-20.el6ev.noarch

How reproducible:
100%

Steps to Reproduce:
1. Create a disk with invalid parameters using RESTAPI:

send the following request using POST to: 

https://<engine-URL>/api/disks

<disk>    
    <name>LunDisk</name>
    <provisioned_size>1073741824</provisioned_size>
    <interface>virtio</interface>
    <format>cow</format>
    <lunStorage>         
        <logical_unit id="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"">
            <address>10.35.1.1</address>
            <port>3260</port>           
            <target>iqn.0000-00.com.aaa:aaa111111111111111-1-aaaa</target>
        </logical_unit>
    </lunStorage>
</disk>

 
Actual results:
Disk is created

Expected results:
Parameters of the disk should be verified by backend on creation

Additional info:
Comment 1 Liron Aravot 2012-10-17 05:23:36 EDT
doesn't seems like a bug to me, there's no difference between performing this operation and to creating a disk with valid server and then lose connection to this server/target whatsoever - we will have the same result (attemp to start vm with non existing lun).

if the user knows the correct server why do we need to require it to be active in the same moment if he plans to run the vm in a week? sys admin can create disk for later use when the storage server is down for example.

when you will try to run the vm with the disk you should fail.
Comment 2 Ayal Baron 2012-10-17 06:09:55 EDT
(In reply to comment #1)
> doesn't seems like a bug to me, there's no difference between performing
> this operation and to creating a disk with valid server and then lose
> connection to this server/target whatsoever - we will have the same result
> (attemp to start vm with non existing lun).

It's not the same result at all nor the same operation.
First of all, we're not 'creating' anything here, we're just defining a LUN to be used.  This LUN is defined on the storage side.
Using only LUNs that are visible to the host makes sure that your credentials and connection info (iqn) are correct (when connected once) and that the LUN ID actually exists.
The LUN ID is determined by the storage server so you cannot have one until your storage server is up.
Defining something and coming back after a week to discover that something fails and you have no idea why and then discovering that you entered incorrect info is not a very good user experience.

Flow should be:
connectStorageServer (error here should fail the operation and report to user that connection info is invalid
getDeviceList (this is needed as it refreshes the storage)
And then define the LUN in the engine if the LUN ID was returned in getDeviceList (if not then need to report the LUN could not be found indicating that possibly lun mapping is incorrect)

> 
> if the user knows the correct server why do we need to require it to be
> active in the same moment if he plans to run the vm in a week? sys admin can
> create disk for later use when the storage server is down for example.
> 
> when you will try to run the vm with the disk you should fail.
Comment 3 Ayal Baron 2012-12-25 09:39:13 EST
Removing devel_ack as I'm not so convinced there aren't use cases where this would be the preferred behaviour (where user would even want to define the LUN before it is defined on the storage, e.g. for DR).
Maybe a flag on the command to test visibility of the LUN on a host (all hosts?)
Andy?

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