Description of problem: If connection exists with some details (username/port/portal/connection/iqn/password) when adding a new lun with the same connection details but with different password (which may be correct opposed to the saved password) the old connection will be used for the LUN and new one won't be added, leading to use the old saved password to the newly added lun. How reproducible: Always Steps to Reproduce: 1. Create a LUN disk through REST-API with wrong password. 2. try to add a domain/disk using the same connection details as the disk, but with the correct password. 3. the connection that'll be used for the newly added domain/disk is the one as the lun disk - instead of having a new connection with the new details. Actual results: the lun is added as using the old connection Expected results: the lun should use a new connection with the new password.
Cannot add a direct LUN via REST due to bug 1176402. Therefore, verification cannot be done for now.
(In reply to Elad from comment #2) > Cannot add a direct LUN via REST due to bug 1176402. Therefore, verification > cannot be done for now. I'm guessing this is a copy-paste error and you meant bug 1220824? (if so, note that this is already merged, and will be available to QE in the next build, so head's up)
(In reply to Allon Mureinik from comment #3) > I'm guessing this is a copy-paste error and you meant bug 1220824? Yes :) > (if so, note that this is already merged, and will be available to QE in the > next build, so head's up)
A new connection with the right credentials is being added to the storage_server_connections table when adding a second LUN with the right credentials to the system while a connection with the wrong credentials already exists in the DB. The new LUN that is being added is using the new storage connection. Verified using rhevm-3.6.0-0.16.master.el6.noarch
RHEV 3.6.0 has been released, setting status to CLOSED CURRENTRELEASE