Bug 845831 - RHEVM - Admin GUI: New Domain dialog sends old parameters instead of current ones
Summary: RHEVM - Admin GUI: New Domain dialog sends old parameters instead of current ...
Keywords:
Status: CLOSED DUPLICATE of bug 815083
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 3.3.0
Assignee: Maor
QA Contact: Daniel Paikov
URL:
Whiteboard: storage
Depends On:
Blocks: 839307
TreeView+ depends on / blocked
 
Reported: 2012-08-05 13:23 UTC by Daniel Paikov
Modified: 2016-02-10 17:05 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-19 18:24:37 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
engine.log (305.02 KB, application/x-compressed-tar)
2012-08-05 13:23 UTC, Daniel Paikov
no flags Details

Description Daniel Paikov 2012-08-05 13:23:18 UTC
Created attachment 602358 [details]
engine.log

* New Domain dialog.
* I entered the following fields: domain PosixFS, format V3, path 10.35.97.44:/vol3, VFS type "fasdfas".
* Domain creation failed because VFS type was gibberish.
* I changed the VFS type to "glusterfs" and tried clicking OK again.
* validateStorageServerConnection is now sent to VDSM with vfstype=glusterfs, but connectStorageServer is still sent with vfstype=fasdfas. There is no way to make the GUI send the current VFS type, even after closing and re-opening the dialog and completely reloading the GUI.


Thread-2125::INFO::2012-08-05 15:54:12,530::logUtils::37::dispatcher::(wrapper) Run and protect: validateStorageServerConnection(domType=6, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', 'connection': '10.35.97.44:/vol3', 'iqn': '', 'portal': '', 'user': '', 'vfs_type': 'glusterfs', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000'}], options=None)
Thread-2125::INFO::2012-08-05 15:54:12,531::logUtils::39::dispatcher::(wrapper) Run and protect: validateStorageServerConnection, Return response: {'statuslist': [{'status': 0, 'id': '00000000-0000-0000-0000-000000000000'}]}
Thread-2126::INFO::2012-08-05 15:54:12,594::logUtils::37::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=6, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', 'connection': '10.35.97.44:/vol3', 'iqn': '', 'portal': '', 'user': '', 'vfs_type': 'fasdfas', 'password': '******', 'id': 'f0304acd-c68a-407d-ae92-108ba5f2ff30'}], options=None)
Thread-2126::INFO::2012-08-05 15:54:12,636::logUtils::39::dispatcher::(wrapper) Run and protect: connectStorageServer, Return response: {'statuslist': [{'status': 477, 'id': 'f0304acd-c68a-407d-ae92-108ba5f2ff30'}]}
Thread-2127::INFO::2012-08-05 15:54:12,887::logUtils::37::dispatcher::(wrapper) Run and protect: createStorageDomain(storageType=6, sdUUID='3642081b-4b20-4b49-b6de-cb96c996ae78', domainName='posix3', typeSpecificArg='10.35.97.44:/vol3', domClass=1, domVersion='3', options=None)
Thread-2133::INFO::2012-08-05 15:54:14,997::logUtils::37::dispatcher::(wrapper) Run and protect: disconnectStorageServer(domType=6, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', 'connection': '10.35.97.44:/vol3', 'iqn': '', 'portal': '', 'user': '', 'vfs_type': 'glusterfs', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000'}], options=None)
Thread-2133::INFO::2012-08-05 15:54:16,537::logUtils::39::dispatcher::(wrapper) Run and protect: disconnectStorageServer, Return response: {'statuslist': [{'status': 477, 'id': '00000000-0000-0000-0000-000000000000'}]}

Comment 1 Daniel Paikov 2012-08-06 08:38:52 UTC
Apparently the connection is saved forever in the storage_server_connections table. Instead of sending the (new) contents of the GUI dialog, we are sending the (old) contents of storage_server_connections.

Comment 2 Maor 2012-08-19 18:24:37 UTC
Should be fixed in the current fix for BZ815083

*** This bug has been marked as a duplicate of bug 815083 ***


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