Skip to content

Conversation

@smarterclayton
Copy link
Contributor

Still remaining - add e2e test for services.

@smarterclayton smarterclayton force-pushed the dns branch 3 times, most recently from 4d2fac8 to e3565c6 Compare March 9, 2015 00:43
@smarterclayton
Copy link
Contributor Author

[test]

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_openshift3/1256/)

@smarterclayton
Copy link
Contributor Author

@deads2k review please

@brenton
Copy link
Contributor

brenton commented Mar 9, 2015

A few (hopefully quick) questions:

  • This is slightly different than how Kubernetes integrates with SkyDNS, right? It seems like they plan to run it in pods. I'm curious why we'd take a different approach. I guess we're mostly enabling a easy out of the box integration. The Kubernetes way would likely still work, right?
  • Is the intention for cluster dns to provide services only for pods? I ask mostly because we'd probably have a few more security requirements if we allow arbitrary clients to contact this service. At a minimum we might want to have some sort of rate limiting.

@smarterclayton
Copy link
Contributor Author

On Mar 9, 2015, at 9:15 AM, Brenton Leanhardt notifications@github.com wrote:

A few (hopefully quick) questions:

This is slightly different than how Kubernetes integrates with SkyDNS, right?
Yes, Kubernetes is copying service data into the etcd schema. This bypasses that.
It seems like they plan to run it in pods. I'm curious why we'd take a different approach. I guess we're mostly enabling a easy out of the box integration. The Kubernetes way would likely still work, right?
Efficiency. If we need to we'll eventually have openshift start dns. However, I think this is just something easier to do on the masters.
Is the intention for cluster dns to provide services only for pods? I ask mostly because we'd probably have a few more security requirements if we allow arbitrary clients to contact this service. At a minimum we might want to have some sort of rate limiting.
Check upstream, they do a few things to limit simultaneous queries. However, this is internal cluster focused right now.

Reply to this email directly or view it on GitHub.

Now you can run `source hack/export-certs.sh <path_to_cert_dir>` and the proper
certs are set in your env
Need to work with go-systemd to see if we can abstract the syscall.CloseOnExec
which is not supported on windows.
Nodes will now assume the master is a DNS server (unless OPENSHIFT_DNS_ADDR
is set) and will pass that value in to the containers they run.

The master will listen on 53 (if it can bind to it) or 8053 to serve DNS
queries.
@smarterclayton
Copy link
Contributor Author

Comments addressed.

@deads2k
Copy link
Contributor

deads2k commented Mar 9, 2015

lgtm [merge]

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_openshift3/1138/) (Image: devenv-fedora_1001)

@openshift-bot
Copy link
Contributor

Evaluated for origin up to dc16de5

openshift-bot pushed a commit that referenced this pull request Mar 9, 2015
@openshift-bot openshift-bot merged commit 8807269 into openshift:master Mar 9, 2015
@smarterclayton smarterclayton deleted the dns branch May 18, 2015 02:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants