Red Hat Bugzilla – Bug 1302402
pxe boot time outs (PXE-E32) on ospd 7 during introspection and during deployment
Last modified: 2016-10-14 12:20:37 EDT
Description of problem: I am testing the bits from rhn (OSPD 7.2?) for an anticipated deployment with similar hardware and I can not get consistent behavior with introspection and can not get a working deployment. I can not get past PXE booting nodes in a consistent manner. Version-Release number of selected component (if applicable): python-rdomanager-oscplugin-0.0.10-22.el7ost.noarch openstack-ironic-common-2015.1.2-2.el7ost.noarch python-ironicclient-0.5.1-12.el7ost.noarch python-ironic-discoverd-1.1.0-8.el7ost.noarch openstack-ironic-conductor-2015.1.2-2.el7ost.noarch openstack-ironic-api-2015.1.2-2.el7ost.noarch openstack-ironic-discoverd-1.1.0-8.el7ost.noarch How reproducible: Always Steps to Reproduce: 1. Follow deployment instructions on access.redhat.com and attempt introspection while viewing nodes consoles. 2. 3. Actual results: PXE-E32: TFTP open timeout on each nodes consoles Expected results: Nodes to boot (consistently) and run through discovery so then they can be provisioned. Additional info: The network is correctly setup as previous builds worked on this hardware. last working version used on this hardware was (python-rdomanager-oscplugin-0.0.10-19.el7ost.noarch) I have a lab network, provisioning network and single vlan-ed network for all other required networks. Several attempts at deploying (this version) on this setup have results in occasionally successful discovery process. However the following deployment has consistently failed everytime afterwards. Something is also adding iptable rules to prevent pxe booting consistently: Chain discovery (1 references) target prot opt source destination DROP all -- anywhere anywhere MAC D4:85:64:79:EB:FC DROP all -- anywhere anywhere MAC D4:85:64:79:AF:C0 ACCEPT all -- anywhere anywhere Even if I manually drop them, the rules reappear after 5-10seconds. This behavior is not exhibited during introspection however I still see timeouts.
Hi Lucas, on MikeO's behalf -- do you mind having a quick look into this one and provide some investigation what might be a cause?
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
Hi! Could you please check if the issue can be reproduced on OSP 10?
(In reply to Dmitry Tantsur from comment #6) > Hi! Could you please check if the issue can be reproduced on OSP 10? I have not seen this(or reproduced it) on any of the OSP10 (Newton) deployments I have done via director.
Thanks! I suspect it was fixed after we updated the shipped firmware.