Description of problem: If the operation runs on storage node times out (but finishes properly), the cluster status of the node will be in NORMAL state but written using red font. Currently, it seems that there is no way to acknowledge this and change the colour to black unless we directly modify the database. Version-Release number of selected component (if applicable): JON 3.2.0 How reproducible: Always Steps to Reproduce: 1. Installed JON Server with two storage nodes; 2. Execute "Repair" operation on the storage node and make it times out; 3. Check the operation history for that node and operation will be considered as "failed" 4. Check the log file and confirm that the "repair" was actually properly finished; Actual results: The cluster status of the storage node will be NORMAL in red. Expected results: The cluster status of the storage node should be NORMAL in red but we should have a way to acknowledge that we read the ERROR/WARN message and to change the colour of the font to black. Additional info:
I'm not exactly sure what this is about, perhaps an issue with SN hook in operationmanager. Asking Jirka to take a closer look for ER04.
Jay is correct in that this does involve the hook in OperationManagerBean. Any time a resource operation is updated/finished, OperationManagerBean gets called. And if it is a storage node operation, StorageNodeOperationsHandlerBean gets called. That hooks was intended for cluster maintenance workflows like adding/removing nodes and repair. If a user submits a storage resource operation that fails for example, this will cause the StorageNode.failedOperation and StorageNode.errorMessage fields to get set which in turns causes the problem reported. I discussed with Jirka changes he is working on that allow the user to manually clear those StorageNode fields on the details view in the storage node admin UI. I think/hope that adequately addresses the problem.
branch: master link: https://github.com/rhq-project/rhq/commit/ed4714ee8 time: 2014-09-25 16:43:51 +0200 commit: ed4714ee81a3b59e2350523cea16e17fc7bc0084 author: Jirka Kremser - jkremser message: [BZ 1083894] - Storage node's cluster status "NORMAL" written in RED cannot be changed - Adding a way to our UI to explicitly reset error message and last failed operation on the rhq_storage_node table. + 1 i-test
branch: release/jon3.3.x link: https://github.com/rhq-project/rhq/commit/5880b8b72 time: 2014-09-25 16:58:33 +0200 commit: 5880b8b72b41950e640f33aa6ddb858f795d92fe author: Jirka Kremser - jkremser message: [BZ 1083894] - Storage node's cluster status "NORMAL" written in RED cannot be changed - Adding a way to our UI to explicitly reset error message and last failed operation on the rhq_storage_node table. (cherry picked from commit ed4714ee81a3b59e2350523cea16e17fc7bc0084) Signed-off-by: Jirka Kremser <jkremser>
Moving to ON_QA as available for test with build: https://brewweb.devel.redhat.com/buildinfo?buildID=388959
issue is still visible in JON3.3 ER04 screen-shot attached reproduction steps: 1. Install JON (server, storage & agent) on IP1 (windows2008) 2. Start server and storage -- agent not connected to server -> storage node installed (stays in status installed) 3. Install JON storage and agent on IP2 and connect to server on IP1, while storage on IP1 is not yet installed 4. Start and connect agent on IP1 -> storage node on IP2 has DOWN state 5. Run deploy node on IP2 After step5. node becomes available (with status normal) but is red and bold After step5. both nodes should be available and hav normal (black) state
Created attachment 946491 [details] node_status
It's working as expected. The red text is denoting there was a failure (either error message was set or an operation didn't run successfully). If you open the storage node details page there should be more information what went wrong and user could ack the notification / re-run the operation / consult the docs / whatever. Note that, I didn't address the root cause of the problem, I've only added the way to ack the error in UI as it was in the "Expected results:" and in John's comment 2.
marking as verified based on comment #9 thank you!