Created attachment 926274 [details] Foreman log Description of problem: During host assignment of controller on a Neutron none HA vxlan deployment, got a DNS error: IP address does not match selected subnet. Conflict DHCP records.. Conflict DNS PTR records.. Note this was a fresh/clean deployment base server and vm's, didn't use resin or clean scripts on setup. Version-Release number of selected component (if applicable): rhel-osp-installer-0.1.9-1.el6ost.noarch foreman-installer-1.5.0-0.6.RC2.el6ost.noarch openstack-foreman-installer-2.0.18-1.el6ost.noarch How reproducible: Not sure first time it happened, I'll try to recreate and update. Steps to Reproduce: 1. Reprovision host server 2. Run staypuft.sh, used Neutron script package. 3. Followed guide, create new deployment Neutron none HA, vxlan. 4. Spun up vm's, discovered them. 5. While assignment controller host, got DNS error Actual results: Failed to deploy due to DNS error Expected results: Setup should complete without error.
Created attachment 926275 [details] DNS error on GUI
On Foreman vm, added to hosts file 192.168.0.9 maca25400654fdd 192.168.0.8 maca25400868096 192.168.0.7 maca25400868097 192.168.0.6 maca25400702875 In hopes this would bypass DNS issue with local resolution, created a new deployment, on controller assignment got a different error on GUI: Unassigned hosts: maca25400702875 MAC address has already been taken Attached production log again if needed, check end of log.
Created attachment 926311 [details] Foreman log with local hosts resolution
Could you elaborate 2nd reproducing step > 2. Run staypuft.sh, used Neutron script package. What does the script do? It seems that there is some cache on that server that results in Conflict DHCP records and Conflict DNS PTR records errors messages. The IP address does not match selected subnet seems like misconfiguration of provisioning. Could you please describe how exactly did you install staypuft?
Staypuft.sh is the script we use to create virtual machines (Foreman,controller Neutron, compute nodes and networking connections). Pretty sure this isn't source of DNS problem, as we used it a couple of times before and after this bug was reported without such DNS issues. If you wish pull down staypuft.sh script from: scp <your-user>@team.virt.bos.redhat.com:/home/tlv/ohochman/staypuft/neutron/* /root/
So the script setups networking and installs some libvirt images? The DNS problem means that foreman DB differs from DNS server state. The foreman-proxy may have not removed some records or someone changed the configuration only on one side manually. It's hard to tell from these information. I'd suggest checking your DNS and DHCP servers to see existing records there and if there are some that are not up to date, delete them. Then try to reproduce. > as we used it a couple of times before and after this bug was reported without such DNS issues. Does that mean that you no longer encounter this issue? If you do, would it be possible to describe how did you run rhel-osp-installer and what options did you use? Would it be possible provide us an environment where it fails?
Yes that basically sums up the script's job. Since then I'd reprovisoned my server twice without hitting this DNS problem. Don't have access to DNS\DHCP management other than basic nslookup as an end user. rhel-osp-instller options basically followed this guide: http://etherpad.corp.redhat.com/Create-staypuft-test-setup Starting on line 71 Options I used are for a Neutron none HA vxlan plus dual compute nodes, Cinder over NFS. Setup it's long gone by now, but if happens again I'll keep it alive and ping you up to access it.
This appears to be resolved in the latest builds