Created attachment 738473 [details] log Description of problem: adding a domain is actually two commands: add domain and attach domain. if we add a new domain and close the new domain window (using the X on right top) we succeed the first command of add but do not even send the second one of attach. I also incountered a race in which we got a CanDoAction that we cannot attach the domain because there are no hosts (probably because the host param came up empty when I closed the window). Version-Release number of selected component (if applicable): sf13.1 How reproducible: 100% Steps to Reproduce: 1. create a new iscsi domain -> select a DC 2. press OK and than close the window using the X 3. Actual results: since this is actually a 2 command action (add and attach) we add the domain but once we close the window we do not send the attach command. Expected results: we should send the attach if a DC is choosen. Additional info: log
The underlying issue here is that the UI handles it as a complex action. I.e. the UI calls three actions consequentially: AddStorageServerConnection, AddNFSStorageDomain, RemoveStorageServerConnection. In order to fix such issues, these actions should be consolidated in a single backend command. A RFE for that should be opened.
(In reply to comment #1) > The underlying issue here is that the UI handles it as a complex action. > I.e. the UI calls three actions consequentially: AddStorageServerConnection, > AddNFSStorageDomain, RemoveStorageServerConnection. In order to fix such > issues, these actions should be consolidated in a single backend command. A > RFE for that should be opened. Why do we allow the user to close the dialog in this state?
(In reply to comment #2) > (In reply to comment #1) > > The underlying issue here is that the UI handles it as a complex action. > > I.e. the UI calls three actions consequentially: AddStorageServerConnection, > > AddNFSStorageDomain, RemoveStorageServerConnection. In order to fix such > > issues, these actions should be consolidated in a single backend command. A > > RFE for that should be opened. > > Why do we allow the user to close the dialog in this state? We always allow the user to close the window by using the 'X' button or ESC (it's been requested in order to overcome issues such as infinite hour-glass).
(In reply to Daniel Erez from comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > The underlying issue here is that the UI handles it as a complex action. > > > I.e. the UI calls three actions consequentially: AddStorageServerConnection, > > > AddNFSStorageDomain, RemoveStorageServerConnection. In order to fix such > > > issues, these actions should be consolidated in a single backend command. A > > > RFE for that should be opened. > > > > Why do we allow the user to close the dialog in this state? > > We always allow the user to close the window by using the 'X' button or ESC > (it's been requested in order to overcome issues such as infinite > hour-glass). Closing a window should *cancel* the operation. Doing half of the requested operation is pointless. To fix cases where system does not respond, we should have a cancel button on all operations that show a progress. Can we implememnt this in for the next version?
(In reply to Nir Soffer from comment #4) > (In reply to Daniel Erez from comment #3) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > The underlying issue here is that the UI handles it as a complex action. > > > > I.e. the UI calls three actions consequentially: AddStorageServerConnection, > > > > AddNFSStorageDomain, RemoveStorageServerConnection. In order to fix such > > > > issues, these actions should be consolidated in a single backend command. A > > > > RFE for that should be opened. > > > > > > Why do we allow the user to close the dialog in this state? > > > > We always allow the user to close the window by using the 'X' button or ESC > > (it's been requested in order to overcome issues such as infinite > > hour-glass). > > Closing a window should *cancel* the operation. Doing half of the requested > operation is pointless. > > To fix cases where system does not respond, we should have a cancel button > on all operations that show a progress. > > Can we implememnt this in for the next version? The underlined issue here, as explained in comment 1, is the 'transaction' handled by the UI (the UI calls the actions consequentially and performs rollback on failure). In order to avoid any more over-complexity in the client, I think that the solution should be in the backend (e.g. consolidate the actions to a single command which handles rollback as needed).
*** Bug 954843 has been marked as a duplicate of this bug. ***
The scenario described in bug 954843 should be tested when implementing the RFE.
The problem is that current the GUI is driving multiple actions against the backend and if you close the dialog before executing one of the steps then it won't proceed. Once we get rid of the storage pool (Bug 757291) then we can convert this to be a single action since 'attach' should simply beome a database operation hence possible to be done in a single transaction.
*** Bug 1184143 has been marked as a duplicate of this bug. ***
*** Bug 1185636 has been marked as a duplicate of this bug. ***
*** Bug 1516698 has been marked as a duplicate of this bug. ***
Is this still relevant?
(In reply to Yaniv Lavi from comment #12) > Is this still relevant? yup
Closing old bugs. If needed please reopen and explain why.