Rubygem-Staypuft: Using different HW in the same deployment may fail the deployment because the NICs are named differently. Environment: rhel-osp-installer-0.1.6-5.el6ost.noarch openstack-foreman-installer-2.0.16-1.el6ost.noarch ruby193-rubygem-foreman_openstack_simplify-0.0.6-8.el6ost.noarch openstack-puppet-modules-2014.1-19.9.el6ost.noarch If different HW is used on bare metal setups, then the NIC specified for external or tenant network in the "service configuration" page might be different for one or more nodes. This will result in a failed deployment. Today we're forced to use the same HW, to assure NICs on nodes are named exactly the same.
This can only be fixed with the network provisioning which is coming in A2
Was able to get all the identical servers to report the same NIC name after adding "biosdevname=0" to the kernel line.
https://github.com/theforeman/foreman-installer-staypuft/pull/75
(In reply to Alexander Chuzhoy from comment #2) > Was able to get all the identical servers to report the same NIC name after > adding "biosdevname=0" to the kernel line. I think we discussed that this would not always work with EL7. A1 sprint(Network phase) will allow to configuring individual hosts and will enable configuring each hardware as needed.
The behavior QE was seeing differed from our understanding of how biosdevname was supposed to act. This presently appears like a reasonably way to let QE move forward on pre-A1 code fairly consistently until we get network management in place.
The solution in comment #2 is valid when using same HW. When using different HW We will still have problem of getting different nic names - Adding : request for 'RN ?' .
Could you verify that biosdevname=0 ended up in the kernel line please? Just want to make sure the change we made did actually land even if it ends up not being the right fix. I don't have a set of different machines to develop a solution for different hardware.
(In reply to Dan Radez from comment #9) > Could you verify that biosdevname=0 ended up in the kernel line please? Just > want to make sure the change we made did actually land even if it ends up > not being the right fix. > > I don't have a set of different machines to develop a solution for different > hardware. Yes, we're settingthe value correctly. After discussion, this bug has been cloned to the next release. The title has been updated. What was fixed as part of this bug: Machines with the same hardware will now get the same nic names because biosdevname is disabled. What the cloned bug will deal with: different hardware profiles.
Reply to comment #9: The string is there: [root@mac047d7b61765e ~]# grep -o 'biosdevname=0' /proc/cmdline biosdevname=0
Verified:rhel-osp-installer-0.1.10-2.el6ost.noarch Using the same HW and specifing the right NICs for tenant/external connection results in successful deployment.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1090.html