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

Use TTL provided by DNS SRV results #692

Closed
grobie opened this Issue May 12, 2015 · 4 comments

Comments

Projects
None yet
3 participants
@grobie
Copy link
Member

grobie commented May 12, 2015

The DNS refresh rate is currently a configuration option. Even better would be to use the TTL provided by the results and leave the authority at the DNS provider.

@fabxc

This comment has been minimized.

Copy link
Member

fabxc commented May 12, 2015

As a default that would be nice. I wouldn't make it mandatory, though.
From what I understand, the TTLs of the result answer section are not that useful, as it doesn't tell us anything about joining and leaving instances. Respectively, Consul sets all TTLs to zero by default.

The SD spec requires to provide a TXT record for each SD name. The TTL of this TXT record specifies the TTL for the SD name. Consul, for example, does not fulfill this requirement.

I assume consul sets the same TTL for all instances and hopes the user is smart and interprets this as the TTL for service as a whole. (Wonder what you are supposed to do if there are 0 instances.) It's unlikely to be alone in not sticking to the spec.
This has obvious implications for an implementation of ours - it would not work for many users.

@brian-brazil

This comment has been minimized.

Copy link
Member

brian-brazil commented Aug 20, 2015

We may want to consider the refresh rate as more of a minimum ttl in this case? Would that need a different paramater name? Considering there's a caching resolver in place in many cases, is there a need to do anything on our side?

@grobie

This comment has been minimized.

Copy link
Member Author

grobie commented Mar 1, 2016

The default has worked fine so far. Feel free to re-open if you see a need for it.

@grobie grobie closed this Mar 1, 2016

simonpasquier pushed a commit to simonpasquier/prometheus that referenced this issue Oct 12, 2017

Point to default port list. (prometheus#692)
It has unintentionally become a defacto listing of exporters, some of whom
we may not wish to list here for various reasons or for which noone has
sent a PR yet. This helps make it easier for users to find exporters,
and potentially aid in development of the ones that are still maturing.
@lock

This comment has been minimized.

Copy link

lock bot commented Mar 24, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Mar 24, 2019

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