Bug 1107579
| Summary: | Operation Decommission fails when undeploying more storage nodes parallely | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Operations Network | Reporter: | Filip Brychta <fbrychta> | ||||
| Component: | Storage Node | Assignee: | Michael Burman <miburman> | ||||
| Status: | CLOSED EOL | QA Contact: | Mike Foley <mfoley> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | JON 3.2.1 | CC: | mfoley | ||||
| Target Milestone: | --- | ||||||
| Target Release: | JON 4.0.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-08-05 14:54:18 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1120418 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Bumping the target release due to time constraints. Work has been started though in the storage_workflow branch. JBoss ON is coming to the end of its product life cycle. For more information regarding this transition, see https://access.redhat.com/articles/3827121. This bug report/request is being closed. If you feel this issue should not be closed or requires further review, please create a new bug report against the latest supported JBoss ON 3.3 version. |
Created attachment 907101 [details] server log Description of problem: I had 4 storage nodes all UP and in Cluster status NORMAL. Then I undeployed 3 of them via UI without waiting for previous storage to be DECOMMISSIONED and one of them was not undeployed because of following error: Undeployment has been aborted due to failed operation [Decommission] Version-Release number of selected component (if applicable): 3.2.0.GA Update 02 Build Number : 055b880:0620403 How reproducible: 2/2 Steps to Reproduce: 1. have 4 storage nodes all UP and in Cluster status NORMAL 2. undeploy 3 of them (those which were deployed later) via UI without waiting for previous storage to be DECOMMISSIONED Actual results: Two of them were correctly DECOMMISSIONED but one was not undeployed and server.log contained following err: 04:59:52,395 ERROR [org.rhq.enterprise.server.storage.StorageNodeOperationsHandlerBean] (EJB default - 7) Undeployment has been aborted due to failed operation [Decommission] on Resource[id=10090, uuid=377893fe-fa64-41c0-a53b-61272f72445f, type={RHQStorage}RHQ Storage Node, key=RHQ Storage Node(fbr-jon32-dr1.bc.jonqe.lab.eng.bos.redhat.com), name=RHQ Storage Node(fbr-jon32-dr1.bc.jonqe.lab.eng.bos.redhat.com), parent=fbr-jon32-dr1.bc.jonqe.lab.eng.bos.redhat.com, version=4.9.0.JON320GA]: java.lang.Exception: Decommission operation failed: org.mc4j.ems.connection.EmsInvocationException:Exception on invocation of [decommission]javax.management.RuntimeMBeanException: java.lang.UnsupportedOperationException: data is currently moving to this node; unable to leave the ring -> javax.management.RuntimeMBeanException:java.lang.UnsupportedOperationException: data is currently moving to this node; unable to leave the ring -> java.lang.UnsupportedOperationException:data is currently moving to this node; unable to leave the ring at org.rhq.core.pc.operation.OperationInvocation.run(OperationInvocation.java:278) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Expected results: All 3 storage nodes are undeployed Additional info: Workaround: navigate to the storage node which failed to undeploy and run operation Decommission manually. Server log attached