On Fri, Feb 3, 2017 at 3:55 PM, Srinivas Naga Kotaru (skotaru)
<[email protected]> wrote:
> Scott
>
> I think we are getting closer to solve this loop.
>
> Do we need to point to /etc/resolve.conf to dnsmasq ? what do you mean? By 
> keeping host IP as first name server in /etc/resolve.conf? our intention is 
> not touch /etc/resolve.conf at all and let be managed by our hosting team 
> using automated batch job periodically. They are responsible of accuracy and 
> integrity of this file
>
> Just updating same name servers of /etc/resolve.conf with  
> /etc/dnsmasq/origin-dns.conf is not just enough to maintain OpenShift and its 
> pods to resolve all types of requests?  Off course we want to disable 
> networkmanger altogether and enable standard network service.

This and setting dnsIP in each node's
/etc/origin/node/node-config.yaml to point at dnsmasq will handle
everything for pods.

/etc/resolv.conf is updated to point the host resolver at dnsmasq
running on the node so that cluster dns works at a host level enabling
docker pushes to 'docker-registry.default.svc.cluster.local'. This
isn't used today but will be in the future.

--
Scott


> Share your thoughts …  appreciated your help so far.
>
> --
> Srinivas Kotaru
>
> On 2/3/17, 12:03 PM, "Scott Dodson" <[email protected]> wrote:
>
>     Oh, the dispatcher script lays down /etc/dnsmasq/origin-dns.conf with
>     a default config as it can be used as a standalone dispatcher without
>     any configuration as long as you're using all defaults However the
>     ansible tasks actually deploy a templated version of that file based
>     on ansible knowledge, mainly if you've reconfigured your
>     portal_network
>
>     The majority of what the dispatcher script does is later in the script
>     and that's writing the nameservers to
>     /etc/dnsmasq.d/origin-upstream-dns.conf whenever an interface is
>     updated to ensure dnsmasq picks up any changes there. So if you were
>     to populate your upstream nameservers into
>     /etc/dnsmasq.d/origin-upstream-dns.conf and then ensure resolv.conf
>     points at dnsmasq you'd have everything we're doing via the
>     dispatcher.
>
>     On Fri, Feb 3, 2017 at 1:49 PM, Srinivas Naga Kotaru (skotaru)
>     <[email protected]> wrote:
>     > If we stop the network manager, will it still trigger the dispatcher 
> script and update both /etc/resolve.conf and /etc/dnsmasq/origin-dns.conf?
>     >
>     > Looking at the shell script, it is pretty much statically filling the 
> origin-dns.conf
>     >
>     > if [[ ${DEVICE_IFACE} == ${def_route_int} && \
>     >        -n "${IP4_NAMESERVERS}" ]]; then
>     >     if [ ! -f /etc/dnsmasq.d/origin-dns.conf ]; then
>     >       cat << EOF > /etc/dnsmasq.d/origin-dns.conf
>     > no-resolv
>     > domain-needed
>     > server=/cluster.local/172.30.0.1
>     > server=/30.172.in-addr.arpa/172.30.0.1
>     > EOF
>     >
>     > If we just manually update the /etc/dnsmasq/origin-dns.conf file with 
> above static content, and stop/disable network manager and update 
> /etc/resolve.conf by using our automated process will work as expected by OCP 
> as it intended by resolving internal, external and cluster discovery without 
> any glitch?
>     >
>     > Really appreciated in advance…
>     >
>     > --
>     > Srinivas Kotaru
>     >
>     > On 2/3/17, 10:36 AM, "Scott Dodson" <[email protected]> wrote:
>     >
>     >     Take a look at the dispatcher script and model whatever you do 
> after that.
>     >     
> https://github.com/openshift/openshift-ansible/blob/master/roles/openshift_node_dnsmasq/files/networkmanager/99-origin-dns.sh
>     >
>     >     On Fri, Feb 3, 2017 at 1:32 PM, Clayton Coleman 
> <[email protected]> wrote:
>     >     > Yes - if you can help us identify the points to bypass (via an 
> issue
>     >     > on openshift-Ansible) it does seem reasonable to just bypass.
>     >     >
>     >     >> On Feb 3, 2017, at 1:19 PM, Srinivas Naga Kotaru (skotaru) 
> <[email protected]> wrote:
>     >     >>
>     >     >> Sorry for pushing but we want to take a decision based on this 
> discussion. If possible we would like to avoid network manager and use 
> regular network service and let our hosting team manage automated process of 
> /etc/resolve.conf and we as platform team update whatever is required to put 
> under /etcc/dnsmasq/*.conf file.
>     >     >>
>     >     >>
>     >     >> --
>     >     >> Srinivas Kotaru
>     >     >>
>     >     >> On 2/3/17, 9:02 AM, "Srinivas Naga Kotaru (skotaru)" 
> <[email protected]> wrote:
>     >     >>
>     >     >>    That is exactly my next question. If we have an automated 
> process to update /etc/resolve.conf file, can’t we also update dnsmasq file 
> and eliminate networkmanaer altogether?
>     >     >>
>     >     >>    I’m assuming contents in /etc/dnsmasq/*.conf file is pretty 
> satic and can we pushed using Ansible or something..
>     >     >>
>     >     >>    Please correct me if am missing anything here.
>     >     >>
>     >     >>
>     >     >>    --
>     >     >>    Srinivas Kotaru
>     >     >>
>     >     >>    On 2/3/17, 8:39 AM, "Clayton Coleman" <[email protected]> 
> wrote:
>     >     >>
>     >     >>        But that's not required if someone has already configured 
> dnsmasq.  We
>     >     >>        don't require you use our dnsmasq configuration, right?
>     >     >>
>     >     >>> On Feb 3, 2017, at 10:57 AM, Scott Dodson <[email protected]> 
> wrote:
>     >     >>>
>     >     >>> Re-sending with proper [email protected] address
>     >     >>>
>     >     >>> dnsmasq services are managed by a NetworkManager dispatcher 
> script and
>     >     >>> that script is also responsible for updating /etc/resolv.conf 
> to point
>     >     >>> at dnsmasq after dnsmasq is started. Therefore NetworkManager is
>     >     >>> required.
>     >     >>>
>     >     >>>> On Fri, Feb 3, 2017 at 10:50 AM, Clayton Coleman 
> <[email protected]> wrote:
>     >     >>>> Hrm - I don't know why it would actually be required, in the 
> sense that
>     >     >>>> nothing dnsmasq is doing is truly dependent on NetworkManager. 
>   Copying
>     >     >>>> Scott
>     >     >>>>
>     >     >>>> On Feb 3, 2017, at 10:38 AM, Nakayama Kenjiro 
> <[email protected]>
>     >     >>>> wrote:
>     >     >>>>
>     >     >>>> Hi,
>     >     >>>>
>     >     >>>> You might have already checked, but according to the docs, it 
> is mandatory.
>     >     >>>>
>     >     >>>> 
> https://docs.openshift.org/latest/install_config/install/prerequisites.html#prereq-dns
>     >     >>>> "NetworkManager is required on the nodes in order to populate 
> dnsmasq with
>     >     >>>> the DNS IP addresses."
>     >     >>>>
>     >     >>>> Regards,
>     >     >>>> Kenjiro
>     >     >>>>
>     >     >>>>
>     >     >>>>
>     >     >>>> On Sat, Feb 4, 2017 at 12:14 AM, Srinivas Naga Kotaru (skotaru)
>     >     >>>> <[email protected]> wrote:
>     >     >>>>>
>     >     >>>>> NetworkManager is mandatory requirement for OCP install and
>     >     >>>>> functionality?? Can we use traditional network service rather 
> network
>     >     >>>>> manager??
>     >     >>>>>
>     >     >>>>> Srinivas Kotaru
>     >     >>>>>
>     >     >>>>> Sent from my iPhone
>     >     >>>>>
>     >     >>>>> _______________________________________________
>     >     >>>>> dev mailing list
>     >     >>>>> [email protected]
>     >     >>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>     >     >>>>
>     >     >>>>
>     >     >>>>
>     >     >>>>
>     >     >>>> --
>     >     >>>> Kenjiro NAKAYAMA <[email protected]>
>     >     >>>> GPG Key fingerprint = ED8F 049D E67A 727D 9A44  8E25 F44B E208 
> C946 5EB9
>     >     >>>>
>     >     >>>> _______________________________________________
>     >     >>>> dev mailing list
>     >     >>>> [email protected]
>     >     >>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>     >     >>
>     >     >>
>     >     >>
>     >     >>
>     >
>     >
>
>

_______________________________________________
dev mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Reply via email to