Skip to content
New issue

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

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

Already on GitHub? # to your account

Change host-based UUIDs to opt-in #3171

Closed
slackpad opened this issue Jun 21, 2017 · 6 comments
Closed

Change host-based UUIDs to opt-in #3171

slackpad opened this issue Jun 21, 2017 · 6 comments
Labels
theme/operator-usability Replaces UX. Anything related to making things easier for the practitioner type/enhancement Proposed improvement or new feature

Comments

@slackpad
Copy link
Contributor

We've had a high number of users struggle to deploy newer versions of Consul with host-based UUIDs because of various edge cases of how the host IDs work in Docker, on specially-provisioned machines, etc. We need to change the sense of this to opt-in instead of opt-out by changing the default for -disable-host-node-id to true.

@slackpad slackpad added type/enhancement Proposed improvement or new feature theme/operator-usability Replaces UX. Anything related to making things easier for the practitioner labels Jun 21, 2017
@preetapan
Copy link
Contributor

Won't this break people not running in containers if they relied on host based node ids for anything? e.g. nagios alerts if consul agent on a host is down.
Perhaps the documentation should make it clear that node-ids are an implementation detail, and not to be relied upon for external systems (monitoring tools etc)

@slackpad
Copy link
Contributor Author

If they relied on host-based IDs they'd have to opt back in, so we will document this as a breaking change for 0.9 that people need to consider when they upgrade. I think for the vast majority of users they are using the node name for things like alerts. The host-based IDs case really just made Consul + Nomad easier to use together because both would use the same IDs for a node, so we can document how to configure them for that.

@nugend
Copy link

nugend commented Jul 6, 2017

Should an issue be opened in the nomad project to highlight this in the Nomad documentation? FWIW, I'm starting to use Nomad and have been using Consul for a while and am really not sure how the host ID actually surfaces in regular usage of either or what would be affected if this wasn't set when using Nomad.

@slackpad
Copy link
Contributor Author

slackpad commented Jul 6, 2017

Hi @nugend Nomad is making a similar default change over on hashicorp/nomad#2735. If you can use host-based IDs, then Nomad and Consul will use the same UUID, so when you see which Nomad node a job is running on you could ssh <uuid>.node.consul, for example. It's a pretty subtle benefit, so we decided to make this opt-in because host-based IDs caused folks trouble in other areas.

@nugend
Copy link

nugend commented Jul 6, 2017

Thanks. Sometimes it's just a little hard to get a handle on some of the concepts from the docs alone.

@Nmishin
Copy link
Contributor

Nmishin commented Feb 13, 2019

hi @slackpad
previously I have a Consul and clients 0.8.4 version, after pugrade Consul server to the 1.3.1 version I sow in logs errors something like that:
consul: RPC failed to server 10.10.9.5:8300: rpc error: rpc error making call: failed inserting node: Error while renaming Node ID: "e1d3e56d-9226-bf3a-571d-2a7e500c37dd": Node name dev-test-zcwf is reserved by node de084f26-6488-71a8-812f-e5f680ef4a17 with name dev-test-zcwf
As I understand dev-test-zcwf node was recreated with the same name, but a new id, what should I do with this?
Do I need set -disable-host-node-id to false for preventing randomly generated node id?
Thanks.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
theme/operator-usability Replaces UX. Anything related to making things easier for the practitioner type/enhancement Proposed improvement or new feature
Projects
None yet
Development

No branches or pull requests

4 participants