Bug 1325100 - Duplicated nameserver is set in the pod when configuring dnsmasq on node
Summary: Duplicated nameserver is set in the pod when configuring dnsmasq on node
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Node
Version: 3.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: ---
Assignee: Solly Ross
QA Contact: DeShuai Ma
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-08 08:46 UTC by Ma xiaoqiang
Modified: 2017-03-03 03:18 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-03 03:18:32 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Ma xiaoqiang 2016-04-08 08:46:14 UTC
Description of problem:
Duplicated nameserver is set in the pod when configuring dnsmasq on node



Version-Release number of selected component (if applicable):
https://github.com/sdodson/openshift-ansible -b cluster-dns


How reproducible:
always

Steps to Reproduce:
1. install env with dnsmasq on node
2. create registry and check the resolv.conf in the pod
#oc exec docker-registry-1-xsagy cat /etc/resolv.conf



Actual results:
search default.svc.cluster.local svc.cluster.local cluster.local openstacklocal lab.eng.nay.redhat.com
nameserver 192.168.0.233
nameserver 192.168.0.233
options ndots:5

Set the duplicated nameserver

Expected results:
Delete the duplicated nameserver

Additional info:

Comment 1 Scott Dodson 2016-04-08 13:30:49 UTC
Unless this is observed to cause any problems I'd like to mark this UpcomingRelease. The first should return reasonable responses for all queries so there should be no need to move on to the second one.

I'm also moving this to Kubernetes because I believe that when dnsIP is set then pod resolv.conf should contain only that value. I believe this is a diff between openshift and kube behavior and I'm not sure how we should address it.

Comment 5 Scott Dodson 2017-03-03 03:18:32 UTC
I'm aware of no adverse conditions created by this. Closing this.


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