Bug 1565510
| Summary: | Need to setup network manually for a cluster imported into RHGS-Console | ||
|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat Gluster Storage | Reporter: | Sweta Anandpara <sanandpa> |
| Component: | vdsm | Assignee: | Sahina Bose <sabose> |
| Status: | CLOSED WONTFIX | QA Contact: | Sweta Anandpara <sanandpa> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | rhgs-3.4 | CC: | amukherj, godas, rhs-bugs, rhsc-qe-bugs, sabose, storage-qa-internal |
| Target Milestone: | --- | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Known Issue | |
| Doc Text: |
Cause: ovirtmgmt network is not assigned on the interface of host
Consequence: Host addition fails with "connectivity check failed" error
Workaround (if any): Edit the "Setup Host networks" under Network sub-tab of Host, and assign the ovirtmgmt network to the host interface and save
Result: Host connectivity is established and host is online
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-04-22 06:29:46 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: | |||
The vdsm rebase has introduced changes working with the networking. Marking this a medium priority as there's a workaround available. Will need to investigate if the same behaviour is seen when adding node to RHV-M console. Gobinda, can you check this? [Not yet marking it for rhgs 3.4] Gobinda - Request for an update here. (In reply to Atin Mukherjee from comment #5) > Gobinda - Request for an update here. I was looking into this but forgot to change the needinfo from Gobinda. I've tested that RHGS 3.4 nodes can be added successfully without any manual steps to RHV-M. For new RHGS deployments, RHGS-C is not likely to be used (as there's a new WA) but RHV-M will be for integrated deployments. Since this flow works, taking this bug out of 3.4 target. Can we close this? RHGS-C is no longer under active maintenance. Customers are advised to use RHGS Web Administration Console to manage gluster deployments. Closing this |
Description of problem: ======================== Had a 6node RHGS 3.4 (glusterfs-3.12.2-7) cluster that was imported into RHGS-Console. All the nodes went to non-operational state, and a traceback was seen in vdsm logs. From UI, after setting up the network manually and changing the boot protocol to 'dhcp', the node was successfully seen online. Traceback (most recent call last): File "/usr/share/vdsm/API.py", line 1575, in setupNetworks supervdsm.getProxy().setupNetworks(networks, bondings, options) File "/usr/lib/python2.7/site-packages/vdsm/supervdsm.py", line 53, in __call__ return callMethod() File "/usr/lib/python2.7/site-packages/vdsm/supervdsm.py", line 51, in <lambda> **kwargs) File "<string>", line 2, in setupNetworks File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _callmethod raise convert_to_error(kind, result) ConfigNetworkError: (10, 'connectivity check failed') Version-Release number of selected component (if applicable): ============================================================= glusterfs-3.12.2-7.el7rhgs.x86_64 vdsm-4.19.43-2.3.el7rhgs.x86_64 How reproducible: ================= Always Steps to Reproduce: ==================== 1. Import a RHGS 3.4 node into RHGS-C 2. Wait for the installation to complete, and the node to show up green Actual results: =============== Step2 fails, shows the node as non-operational. Boot protocol is defaulted to 'None'. Expected results: ================== Node should show up as successfully installed, and the user should be able to manage the same. Additional info: ================ Either we fix this, or we update our documents with additional step(s), once they update their setup to RHGS 3.4.