|Summary:||[Docs] [Director] Overcloud deployment fails on nodes if one of the redundant interfaces is marked as down|
|Product:||Red Hat OpenStack||Reporter:||VIKRANT <vaggarwa>|
|Status:||NEW ---||QA Contact:||RHOS Documentation Team <rhos-docs>|
|Version:||8.0 (Liberty)||CC:||adahms, cllewellyn, dcadzow, dmacpher, jraju, srevivo, vaggarwa|
|Target Milestone:||---||Keywords:||Documentation, Reopened|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2018-09-24 23:23:07 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description VIKRANT 2016-08-04 05:00:30 UTC
Description of problem: Overcloud deployment fails on nodes if one of the redundant interfaces is marked as down Version-Release number of selected component (if applicable): RHEL OSP 8 How reproducible: Everytime for Cu. Steps to Reproduce: 1. use bonded interfaces with two physical adaptors. Using VLANs to isolate the subnets. 2. If one of the physical adaptors is marked as down the overcloud fails to deploy. It appears that the network configuration test fails and the it rolls back before retrying. 3. Actual results: Expected results: Additional info: We should add this information explicitly in Red Hat guide that deployment can fail due to "faulty hardware". or we need to have HW in healthy state for successful deployment.
Comment 2 Dan Macpherson 2016-08-04 05:12:32 UTC
(In reply to VIKRANT from comment #0) > Additional info: > > We should add this information explicitly in Red Hat guide that deployment > can fail due to "faulty hardware". or we need to have HW in healthy state > for successful deployment. Hi Vikrant, Thanks for your input. However, I'm not sure whether this suggestion as it is will result in much useful documentation. I say this because it seems like we're stating the obvious (i.e. "If you want a successful deployment, don't use faulty hardware.") Is there any further context you can provide for this request?
Comment 3 VIKRANT 2016-08-04 05:17:33 UTC
Hi Dan, Thanks for prompt response. Cu specifically faced the deployment issue while using A/P bonding configuration. In case of A/P bonding, AFAIK ideally one active interface should be sufficient for bonding but during OSP deployment it got failed because other bonded interface was in failed state.
Comment 4 Dan Macpherson 2016-08-04 05:42:47 UTC
Thanks, Vikrant. That adds a bit more context. Do you know if Cu was using OVS bonding or Linux bonding? Also, what bond options were they using? (I ask because we've got a section for Overcloud NIC bonding that has a bunch of caveats: https://access.redhat.com/documentation/en/red-hat-openstack-platform/8/paged/director-installation-and-usage/appendix-g-open-vswitch-bonding-options -- I know OVS bonding is a little temperamental, which might explain the issue Cu had)
Comment 7 Andrew Dahms 2016-08-08 12:16:49 UTC
Moving to 'NEW' while assigned to the default assignee.
Comment 8 Charlie Llewellyn 2016-08-08 13:41:44 UTC
Hi Dan, We are using OVS bonding in bond_mode=active-backup. Thanks