Bug 1734539

Summary: [OSP] openshift installer needs to allow nameserver to be set on tenant networks it creates
Product: OpenShift Container Platform Reporter: August Simonelli <asimonel>
Component: InstallerAssignee: Eric Duen <eduen>
Installer sub component: openshift-installer QA Contact: David Sanz <dsanzmor>
Status: CLOSED ERRATA Docs Contact:
Severity: medium    
Priority: unspecified CC: adahiya, egarcia, jialiu, larizmen, m.andre, ppitonak
Version: 4.2.0Keywords: Reopened
Target Milestone: ---   
Target Release: 4.3.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-01-23 11:04:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description August Simonelli 2019-07-30 19:56:52 UTC
Description of problem:

During an OpenShift install every instance expects DNS resolution OOTB. 

This may not be the default condition in many customers as many want their tenants to add this when they create a private network. Simply, they don't want a global nameserver set.

Right now, the OCP 4.2 installer creates the tenant network WITHOUT any nameserver set

This functionality to create a nameserver on the those networks used be in the code at: https://github.com/openshift/installer/commit/e78dda8acbbe358d3a2d141005889ee55e7b74b6#diff-2e9ee288606583af9d7aff21a6a2cf81

But was removed.

The installer should allow clouds deployed without default nameservers made available OOTB to set a nameserver on the networks it creates. This could work like the reverted commited listed above, but should, ideally, be variablised.


Version-Release number of the following components:
 oc version
Client Version: version.Info{Major:"4", Minor:"2+", GitVersion:"v4.2.0", GitCommit:"2e9d4a117", GitTreeState:"clean", BuildDate:"2019-07-28T17:15:26Z", GoVersion:"go1.12.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.0+463e263", GitCommit:"463e263", GitTreeState:"clean", BuildDate:"2019-07-30T02:08:56Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
[stack@undercloud installer]$ bin/openshift-install version
bin/openshift-install unreleased-master-1456-gc998f555539fbf1e07a78bc5f55a20798c072d2a-dirty
built from commit c998f555539fbf1e07a78bc5f55a20798c072d2a
release image registry.svc.ci.openshift.org/origin/release:4.2


How reproducible:
Install with 4.2 installer.

Steps to Reproduce:
1. Install with version above
2. Private networks will be created without nameserver resolution
3.

Actual results:
Instances can't resolve and registry pulls will fail. The install will time out.

Expected results:
Install succeeds.

Additional info:

I am aware that to provide this type functionality to tenant networks OOTB you can set this with director by doing something like:

NeutronDhcpAgentDnsmasqDnsServers: 192.168.122.1

Pointing at a working nameserver.

This setting, from the docs, "allows dnsmasq_dns_servers to be configured for Neutron DHCP Agent with a new parameter (NeutronDhcpAgentDnsmasqDnsServers, default to [])."

Ref: https://docs.openstack.org/releasenotes/tripleo-heat-templates/ocata.html

Essentially this lets Neutron's DHCP act as a DNS server for all instances and provides it by default. 

But this is global setting and may not be desirable or even possible in many environments. For this reason I think the installer should allow customers to set DNS on the private subnets it builds.

Comment 5 Abhinav Dahiya 2019-08-13 00:01:41 UTC
This seems like an RFE and not a bug fix?

Comment 6 Scott Dodson 2019-08-13 20:04:53 UTC
This should be tracked in JIRA.

Comment 7 egarcia 2019-08-15 18:07:16 UTC
Whether or not its a bug or a feature, many openstack providers use alternative dns services from those run by openstack, and this would be very restrictive to the scope of who is able to run the installer.

Comment 9 Martin André 2019-10-09 09:37:17 UTC
The BZ was originally closed because it was targeted at 4.2.0 while it was already in feature freeze. Re-opening, targeting 4.3.0 this time.

Comment 10 egarcia 2019-10-23 14:58:08 UTC
Awaiting Code Review: https://github.com/openshift/installer/pull/2132

Comment 12 David Sanz 2019-10-29 09:09:25 UTC
Verified

Comment 13 Eric Duen 2019-11-13 18:25:55 UTC
*** Bug 1765518 has been marked as a duplicate of this bug. ***

Comment 15 errata-xmlrpc 2020-01-23 11:04:29 UTC
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/RHBA-2020:0062