-
Notifications
You must be signed in to change notification settings - Fork 94
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
Fix DNS SRV port not used in cluster.join-addresses #766
Conversation
Thanks for opening this! @tpaschalis @wildum can one of you take a look at this one? You know more about this code than I do. |
docs/sources/reference/cli/run.md
Outdated
@@ -107,6 +107,7 @@ If `--cluster.advertise-interfaces` isn't explicitly set, {{< param "PRODUCT_NAM | |||
Since Windows doesn't use the interface names `eth0` or `en0`, Windows users must explicitly pass at least one valid network interface for `--cluster.advertise-interfaces` or a value for `--cluster.advertise-address`. | |||
|
|||
The comma-separated list of addresses provided in `--cluster.join-addresses` can either be IP addresses with an optional port, or DNS records to lookup. | |||
If the address is a DNS record, it will be looked up as an A/AAAA record if the port is explicitly provided, otherwise it will be looked up as a SRV record and the port in the SRV record will be used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if the intention was different here, but we still always perform a LookupSRV
.
Also, depending on how addresses are discovered (one example is a Headless kubernetes service, but it can be any number of ways), the port is not guaranteed to be present or set to the same port that nodes use as their listen addresses. So that's why I feel making use of the default port on the local node's listen address is a sensible default here.
Hey @devsunb, how's it going? First off, apologies for the belated response here, it shouldn't have taken so long for me to get back to you here. Could you explain more about the intentions of this PR? As I said in the previous comment, I feel this would depend on DNS SRV records that are explicitly defined for the usecase of Alloy clustering and may break usecases where a more generic record is used for discovery. |
@tpaschalis Thank you for your response. Let me give you some background on this PR. I am using AWS ECS and AWS Service Discovery for internal DNS between containers. In this context, I wanted to cluster Alloy using A record, but when I passed just the domain name with the I found that the
At first, I thought it was because Alloy didn't define behavior for A record in 2-ii, so I wrote code for A record support in that part and it worked fine, so I was going to create a PR, but when I looked a little further into the code, I found that hashicorp/memberlist (which Alloy uses for peer clustering) already has code for A record support. So I reverted the change and instead specified the port while passing the domain name as And I decided to change the direction of the PR and make it a PR to document the specifics of the However, there was one question that remained, in 2-ii, since the SRV record contains the port, why is it using the default port instead of using it, so I fixed it and included it in the PR. To summarize, there are the following cases when using the
Since it seems to be documented by #910 that Alloy does not support case 4, why not include in the documentation that there is a way to use A record for Alloy clustering as well, for people in similar situations to mine? In any case, I closed this PR because I understood why the main request won't merge. |
PR Description
Fixed an issue where DNS SRV record's port is not used in
cluster.join-addresses
.Which issue(s) this PR fixes
Notes to the Reviewer
PR Checklist