Open abutcher opened 8 years ago
Instead of the current model, where resolv.conf is updated to point to the dns service on the bastion, I would recommend keeping dnsmasq enabled and laying down a NetworkManager/dnsmasq dropfile that would configure the use of the bastion dns service for the example.com domain.
-P skip_dns=true (which is considered in the linked OSv3 file - https://github.com/redhat-openstack/openshift-on-openstack/blob/master/templates/var/lib/ansible/group_vars/OSv3.yml#L14) should satisfy this RFE
In README it's mentioned only in the NOTE in https://github.com/redhat-openstack/openshift-on-openstack#setting-dns, we should make this clearer.
@jprovaznik does that allow for all of the host resolution to work as well? If so, are host entries being added on each of the hosts, or is there still some requirement on ensuring dns resolution externally?
is skip_dns is used, then OpenShift cluster hostnames are written into /etc/hosts on bastion node, this file is copied to each node (also when new nodes are added): https://github.com/redhat-openstack/openshift-on-openstack/blob/master/templates/var/lib/ansible/playbooks/dns.yml#L5
/etc/resolv.conf is updated with dns passed in dns_nameserver heat parameter (default is 8.8.8.8). Then openshift_use_dnsmasq is unset (so defaults to True) and openshift-ansible should take care of setting dnsmasq or network-manager (correct me if not) on each node.
No additional steps should be required for dns resolving on nodes. For users accessing OpenShift from outside you need to set wildcard+LB hostnames (the "Setting DNS" section).
Note that skip_dns didn't work for me with flannel, didn't get to investigate this further.
Back to the original note: It seems that there is a requirement and an assumption:
The first is incontrovertible, but the second is, I think an issue for discussion.
The most recent heat stack demonstrates the use of an external DNS service deployed as a stack with DDNS updates enabled. If DNS will be used to publish services (as DNS is designed to do) it would seem appropriate to use a robust distributed manageable DNS service. dnsmasq requires updates to the node host file and a restart or reload of the daemon on each node where an update occurs. A proper DNS service allows dynamic updates through programmatic means. I wonder if dnsmasq on each node is the best available solution.
Dnsmasq is currently disabled and this won't be a big deal for 3.2 or 3.3 but it will be important configuration when nodes begin talking to services like the registry via dns. /cc @detiber