Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't hardcode the kubernetes.default FQDN in local-docker #940

Merged

Conversation

3 participants
@lminaudier
Copy link
Contributor

lminaudier commented Feb 26, 2019

The default search domain for clusters can be changed and
kubernetes.default.svc.cluster.local may not respond leading to
telepresence timing out when starting the local container.

So I propose to not use a FQDN.


Make sure every source file you touch has the standard license header.

Before landing, add a changelog entry as a file newsfragments/issue_number.type, where type is one of incompat, feature, bugfix, or misc. Preview the changelog with virtualenv/bin/towncrier --draft.

E.g., 532.bugfix would contain the text "Telepresence should no longer get confused looking for the route to the host when using the container method."

Don't hardcode the kubernetes.default FQDN in local-docker
The default search domain for clusters can be changed and
kubernetes.default.svc.cluster.local may not respond leading to
telepresence timing out when starting the local container.
@LukeShu

This comment has been minimized.

Copy link
Contributor

LukeShu commented Mar 6, 2019

Hey, just to avoid leaving you hanging: The lead Telepresence developer, @ark3, is offline for a while because of an injury, and this is something I think we should get his opinion on before merging.

I suspect the more "correct" thing to do would be to construct the FQDN based on the zone, rather than hard-coding a fixed string. I also suspect that this may cause funny things if/when the DNS support switches over to teleproxy-based DNS, which does some really funny things with the DNS search path.

@lminaudier

This comment has been minimized.

Copy link
Contributor Author

lminaudier commented Mar 7, 2019

Oh I am so sorry to hear that. Feel better @ark3.
Thanks for the headsup. No worries. Totally understand.

@ark3 ark3 added this to In progress in Tel Tracker via automation Mar 29, 2019

@ark3

This comment has been minimized.

Copy link
Contributor

ark3 commented Apr 1, 2019

Thank you for the PR. I think your solution is correct. As parse_resolv_conf in container.py already sets up the network container's DNS based directly on the proxy pod's resolv.conf, doing a lookup for kubernetes.default should be correct.

And let's worry about Teleproxy integration later. 😉

@ark3 ark3 merged commit 0cc86a6 into telepresenceio:master Apr 1, 2019

1 check passed

deploy/netlify Deploy preview ready!
Details

Tel Tracker automation moved this from In progress to Done Apr 1, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.