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

Identify services using both the ID and the Node #414

Conversation

alvaroaleman
Copy link
Contributor

This aligns Fabio with the Consul docs[0] which state that
a serviceID has to be unique per agent but not cluster wide.

Fixes #383

[0] https://www.consul.io/api/agent/service.html#id

@magiconair
Copy link
Contributor

That looks simple enough. Can you update registry/consul/passing_test.go? It is time for me to also write a test for service.go

This aligns Fabio with the Consul docs[0] which state that
a serviceID has to be unique per agent but not cluster wide.

Fixes fabiolb#383

[0] https://www.consul.io/api/agent/service.html#id
@alvaroaleman alvaroaleman force-pushed the do-not-require-clusterwide-unique-serviceid branch from aa84cc7 to e41126e Compare December 16, 2017 14:47
@alvaroaleman
Copy link
Contributor Author

Updated passing_test.go.

Thanks btw for your awesome work and really fast reaction on issues/PRs!

@ygersie
Copy link

ygersie commented Dec 18, 2017

I think in general c.Node == svc.Node should be the first thing to evaluate, right? The Node will always be the most specific condition in that loop, while for example serfHealth will be hit for every consul agent.

// Make the node part of the id, because according to the Consul docs
// the ServiceID is unique per agent but not cluster wide
// https://www.consul.io/api/agent/service.html#id
name, id := check.ServiceName, check.ServiceID+check.Node
Copy link

@ygersie ygersie Dec 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to align with what Consul servers internally do:
fmt.Sprintf("%s.%s", check.Node, check.ServiceID)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll fix that in a subsequent commit.

@alvaroaleman
Copy link
Contributor Author

@dropje86 Does that actually result in Go not evaluating the other conditionals?

@magiconair Is there still something missing from your POV?

@ygersie
Copy link

ygersie commented Dec 19, 2017

@alvaroaleman Although not clearly documented, Go does use "Short circuit evaluation". See here: https://kuree.gitbooks.io/the-go-programming-language-report/content/22/text.html

@alvaroaleman
Copy link
Contributor Author

Interesting, thanks for the link @dropje86!

I've added a second commit that simplifies the conditional logic in passing.go and avoids unnecessary evaluations, depending on what @magiconair thinks I can either squash it or put it in a separate PR.

@magiconair
Copy link
Contributor

Sorry, got a bit sick. I'll do this probably tomorrow and then try to run a release right away. Time to use goreleaser.

@magiconair magiconair merged commit 8b9a885 into fabiolb:master Dec 21, 2017
@magiconair
Copy link
Contributor

@alvaroaleman Thanks for the patch. Merged it and made some small changes in subsequent commits.

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.

None yet

3 participants