Red Hat Bugzilla – Bug 1275845
Add an already exist storage connection to a data center with a storage domain should fail
Last modified: 2017-07-28 10:18:18 EDT
Created attachment 1087086 [details] print screen Description of problem: When adding an existing storage connection again, it should fail. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Login to all iscsi targets 2. Add new storage domain 3. Add an already existing storage connection Actual results: It is possible to add the same connection twice Expected results: It shouldn't be allowed to add the same storage connection twice Additional info:
Created attachment 1087087 [details] engine and vdsm logs
I don't understand the flow. What exactly are you adding, and how are you doing this? If it's done via REST - please provide the exact requests you're sending. if it's done via the GUI, please provide screenshots.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
I'm trying to add a storage connection that located in DB under storage_server_connections table (attached print screen) The POST request: https://jenkins-vm-11.scl.lab.tlv.redhat.com/ovirt-engine/api/storageconnections body: <storage_connection> <address>10.35.160.107</address> <type>iscsi</type> <port>3260</port> <target>iqn.1992-04.com.emc:cx.ckm00121000438.b7</target> </storage_connection>
Moving out all non blocker\exceptions.
When testing with the current master (commit 121657e), I get the expected 409 error when testing this scenario: <fault> <detail>[Cannot add Storage Connection. Storage connection already exists.]</detail> <reason>Operation Failed</reason> </fault> It seems that the relevant code has been there for a while. Setting to ON_QA for QA to verify on 4.1.5, but realistically this can even be verified in 4.1.4 if QE have the capacity.
Thanks Allon, Verified for both master and 4.1.4.