Bug 1129536 - DNS issue during host assignment
Summary: DNS issue during host assignment
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: foreman-proxy
Version: 5.0 (RHEL 6)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: Installer
Assignee: Dominic Cleal
QA Contact: Omri Hochman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-13 06:11 UTC by Tzach Shefi
Modified: 2015-04-30 16:24 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-30 16:24:04 UTC


Attachments (Terms of Use)
Foreman log (1.01 MB, text/plain)
2014-08-13 06:11 UTC, Tzach Shefi
no flags Details
DNS error on GUI (143.29 KB, image/png)
2014-08-13 06:12 UTC, Tzach Shefi
no flags Details
Foreman log with local hosts resolution (1.56 MB, text/plain)
2014-08-13 08:26 UTC, Tzach Shefi
no flags Details

Description Tzach Shefi 2014-08-13 06:11:30 UTC
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.

Comment 1 Tzach Shefi 2014-08-13 06:12:00 UTC
Created attachment 926275 [details]
DNS error on GUI

Comment 5 Tzach Shefi 2014-08-13 08:24:27 UTC
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.

Comment 6 Tzach Shefi 2014-08-13 08:26:06 UTC
Created attachment 926311 [details]
Foreman log with local hosts resolution

Comment 7 Marek Hulan 2014-08-14 06:51:15 UTC
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?

Comment 8 Tzach Shefi 2014-08-20 05:35:52 UTC
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/

Comment 9 Marek Hulan 2014-08-21 11:36:13 UTC
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?

Comment 10 Tzach Shefi 2014-08-21 13:41:08 UTC
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.

Comment 11 Mike Burns 2015-04-30 16:24:04 UTC
This appears to be resolved in the latest builds


Note You need to log in before you can comment on or make changes to this bug.