Description of problem: I was trying to setup a OSP deployment when I saw the following problem error: Possible DNS issues detected: Undercloud DNS (192.168.175.10 ) does not match Satellite DNS (192.168.175.10) Click here update OpenStack DNS addresses to match Satellite Note there is an extra space after the Undercloud DNS, however when you look in the resolv.conf on the undercloud system. I also ran the /etc/resolv.conf through od -cv with this result: [root@localhost ~]# od -cv /etc/resolv.conf 0000000 \n n a m e s e r v e r 1 9 2 . 0000020 1 6 8 . 1 7 5 . 1 0 \n 0000033 As you can see there is no space, but only a LF where you would expect one. Version-Release number of selected component (if applicable): QCI-1.1-RHEL-7-20170105.t.0 How reproducible: Only seen once so far with the first deploy of the new fusor system. Landon says he has seen this before. Steps to Reproduce: 1. Create an OSP deployment and get to the Detect Nodes screen. 2. Enter the information for the undercloud. Actual results: The error mentioned above occurs. Expected results: No error should occur provided your DNS is configured appropriately on the undercloud. Additional info:
If you can reproduce this can you provide me access to the setup before allowing it to update anything, please. I just performed a clean undercloud install and was not prompted to update anything on running through the detection.
I've only seen it once, and haven't seen it since then. If I see it again I will let you know.
Since we can't reproduce this I'm going to close it for now. It's possible it actually caught an extra invisible or whitespace character, I suppose. If you're able to reproduce it please re-open the ticket and let me have a look at the host.
Happened again with latest composes: QCI-1.1-RHEL-7-20170112.t.0 QCIOOO-10.0-RHEL-7-20170113.t.0 Turns out if you refresh it goes away, but if you keep refreshing it will show up again.
We run a ruby one liner on the director to get the nameserver client.execute('ruby -e "require \'resolv\'; puts Resolv::DNS::Config.new.lazy_initialize.nameserver_port.first.first"', io) dns = io.string This usually returns: "192.168.175.10\r\n" Sometimes though it returns: <jmontleo> "192.168.175.10\n\r\n" irb(main):011:0> "192.168.175.10\r\n".chomp => "192.168.175.10" irb(main):012:0> "192.168.175.10\r\n".chomp('') => "192.168.175.10" irb(main):013:0> "192.168.175.10\n\r\n".chomp => "192.168.175.10\n" irb(main):014:0> "192.168.175.10\n\r\n".chomp('') => "192.168.175.10" .chomp works in the first case. .chomp('') works in either. I'm still curious why this happens and would like to consult with a couple of my peers to see if we can get to the root of that, but this will fix the problem seen in the UI: https://github.com/fusor/fusor/pull/1342
Verified on QCI-1.1-RHEL-7-20170120.t.0.
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. https://access.redhat.com/errata/RHEA-2017:0335