Red Hat Bugzilla – Bug 866580
[engine]Able to add directLUN disk through REST API with incorrect parameters
Last modified: 2016-02-10 12:09:26 EST
Created attachment 627552 [details]
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):
Steps to Reproduce:
1. Create a disk with invalid parameters using RESTAPI:
send the following request using POST to:
Disk is created
Parameters of the disk should be verified by backend on creation
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.
(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.
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?)