Created attachment 849783 [details] exceprt of the logs of the failing engine Description of problem: The configuration of the first (and possibly, but not verified, any other) ISCSI data domain fails with internal error, if 1. the iscsi target is NOT automatically found and the list prefilled 2. a discovery is manually issued 3. the iscsi target requires password authentication Logs reveal an SQL exception: 2014-01-09 11:49:58,823 ERROR [org.ovirt.engine.core.bll.storage.AddSANStorageDomainCommand] (http--0.0.0.0-8080-1) [151d3565] Command org.ovirt.engine.core.bll.storage.AddSANStorageDomainCommand throw exception: org.springframework.dao.DataIntegrityViolationException: CallableStatementCallback; SQL [{call insertstorage_server_connections(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: value too long for type character varying(50) Where: SQL statement "INSERT INTO storage_server_connections(connection, id, iqn, port,portal, password, storage_type, user_name,mount_options,vfs_type,nfs_version,nfs_timeo,nfs_retrans) VALUES(v_connection, v_id, v_iqn,v_port,v_portal, v_password, v_storage_type, v_user_name,v_mount_options,v_vfs_type,v_nfs_version,v_nfs_timeo,v_nfs_retrans)" PL/pgSQL function insertstorage_server_connections(character varying,character varying,character varying,character varying,character varying,text,integer,character varying,character varying,character varying,character varying,smallint,smallint) line 3 at SQL statement; nested exception is org.postgresql.util.PSQLException: ERROR: value too long for type character varying(50) Where: SQL statement "INSERT INTO storage_server_connections(connection, id, iqn, port,portal, password, storage_type, user_name,mount_options,vfs_type,nfs_version,nfs_timeo,nfs_retrans) VALUES(v_connection, v_id, v_iqn,v_port,v_portal, v_password, v_storage_type, v_user_name,v_mount_options,v_vfs_type,v_nfs_version,v_nfs_timeo,v_nfs_retrans)" PL/pgSQL function insertstorage_server_connections(character varying,character varying,character varying,character varying,character varying,text,integer,character varying,character varying,character varying,character varying,smallint,smallint) line 3 at SQL statement This happens after a discovery is performed. If the target list is prefilled, everything works just fine. Version-Release number of selected component (if applicable): git master snapshot starting at least from commit 34668585cff3a60407a08acc2563b18ab30c08b3 (will be 3.4.0) How reproducible: 100% of times Steps to Reproduce: 1. download and compile engine from gerrit 2. create the db and run engine-setup; configure the engine for ISCSI data domain 3. try to configure the ISCSI domain following the steps outlined here www.ovirt.org/Quick_Start_Guide#Create_an_iSCSI_Data_Domain 4. Fill all the fields: hostname, password, enable authentication, fill username/password 4. Issue a discovery; the target should now show up 5. Click "OK", should pop up internal error. Actual results: Operation fails with internal error Expected results: the target should be added Additional info: On VDSM side everything seems to work OK. From investigation, it seems the only thing which actually fails is the registration of the connection into the DBMS.
A possible solution has been found and it is being discussed on gerrit http://gerrit.ovirt.org/#/c/23133
It seems that one of the storage_server_connections is too short Since the error message complains about a column with varchar(50), we have 5 candidates : engine_917039=> \d storage_server_connections Table "public.storage_server_connections" Column | Type | Modifiers ---------------+------------------------+----------- id | character varying(50) | not null connection | character varying(250) | not null user_name | character varying(50) | password | character varying(50) | iqn | character varying(128) | port | character varying(50) | portal | character varying(50) | storage_type | integer | not null mount_options | character varying(500) | vfs_type | character varying(128) | nfs_version | character varying(4) | nfs_timeo | smallint | nfs_retrans | smallint | Maybe it worth to turn PG log messages to record all queries , reproduce and attach the PG log so we can see the exact value causing to this PG log settings should be in /var/lib/pgsql/data/postgres.conf
http://gerrit.ovirt.org/#/c/23133/ fixes for me. Do we still need the logs?
(In reply to Francesco Romani from comment #3) > http://gerrit.ovirt.org/#/c/23133/ fixes for me. Do we still need the logs? No
Fixes should be in ovirt-3.4.0-beta2. Assignee please check.
The fix seems to NOT be merged in git tag ovirt-engine-3.4.0_beta2
(In reply to Francesco Romani from comment #6) > The fix seems to NOT be merged in git tag ovirt-engine-3.4.0_beta2 Thanks, moving back to modified.
reproduced using 3.4 av2 Steps to Reproduce: 1. set CHAP on ISCSI target ports, 2. Create new ISCSI SD - enable authentication, fill username/password Issue a discovery; the target should now show up 3. Click "OK", should pop up internal error. from logs : ======= 2014-03-05 11:11:58,061 ERROR [org.ovirt.engine.core.bll.storage.AddSANStorageDomainCommand] (ajp-/127.0.0.1:8702-2) [3e89a9e5] Command org.ovirt.engine.core.bll.storage.AddSANStorageDomainComm and throw exception: org.springframework.dao.DataIntegrityViolationException: CallableStatementCallback; SQL [{call insertstorage_server_connections(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ER ROR: value too long for type character varying(50)
Created attachment 870887 [details] logs
The fix was implemented as DB upgrade script. So, if the fix DB was *not* created from scratch for he installation of the engine 3.4.0, or was not updated, the bug will still be present.
Hi, how did you created the database for the test? As I stated in https://bugzilla.redhat.com/show_bug.cgi?id=1052839#c10 above, it is possible the fix was not actually deployed, so the bug is still present.
Do we need this fix for 3.4.0? I think 3.4.1 is enough, don't you think
Well it was targeted for 3.4.0, and I mistankely thought it was merged already in the 3.4.0 branch, so I took the chance to backport it for 3.4.0 also. That said, This bug looks like a quite rare corner case and noone else has stumbled into it AFAIK, so I think there is no urgent need to rush it to merge in 3.4.0. If it makes into the release we're all good, otherwise it could wait 3.4.1.
retargeted for 3.4.1. http://gerrit.ovirt.org/#/c/23133/ merged (master) http://gerrit.ovirt.org/#/c/25893/ merged (ovirt 3.4)
This is an automated message oVirt 3.4.1 has been released: * should fix your issue * should be available at your local mirror within two days. If problems still persist, please make note of it in this bug report.
*** Bug 1126856 has been marked as a duplicate of this bug. ***