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

Reproducible Node ID #2277

Merged
merged 8 commits into from
Feb 2, 2017
Merged

Reproducible Node ID #2277

merged 8 commits into from
Feb 2, 2017

Conversation

sean-
Copy link
Contributor

@sean- sean- commented Feb 2, 2017

With Consul 0.7.4 supporting a consistent Node ID, it would be nice if Nomad shared its generation of Node IDs with Consul. The following is now true in Consul. Assuming the following output from the start of a Consul agent:

==> Consul agent running!
           Version: 'v0.7.3-43-gc5e140c-dev (c5e140c+CHANGES)'
           Node ID: '40e4a748-2192-161a-0510-9bf59fe950b5'
         Node name: 'myhost'

it is now possible to lookup nodes by their Node Name or Node ID, or a
prefix match of the Node ID, with the following caveats re: the prefix
match:

  1. first eight digits of the Node ID are a required minimum (eight was chosen as an arbitrary number so that people don't grow a dependency on it functioning with a prefix match of two characters and then watch something break because ambiguous lookups will return an empty set)
  2. the length of the Node ID must be an even number or no result will be returned.
% dig @127.0.0.1 -p 8600 myhost.node.dc1.consul.
myhost.node.dc1.consul.	0	IN	A	127.0.0.1
% dig @127.0.0.1 -p 8600 40e4a748-2192-161a-0510-9bf59fe950b5.node.dc1.consul.
40e4a748-2192-161a-0510-9bf59fe950b5.node.dc1.consul. 0	IN A 127.0.0.1
% dig @127.0.0.1 -p 8600 40e4a748.node.dc1.consul.
40e4a748.node.dc1.consul. 0	IN	A	127.0.0.1
% dig @127.0.0.1 -p 8600 40e4a74821.node.dc1.consul.
40e4a74821.node.dc1.consul. 0	IN	A	127.0.0.1
% dig @127.0.0.1 -p 8600 40e4a748-21.node.dc1.consul.
40e4a748-21.node.dc1.consul. 0	IN	A	127.0.0.1

This PR, in effect, applies a similar Node ID creation treatment to Nomad and as a result solves the UX issue where a Nomad Node ID must be passed to nomad node-status to find the hostname. The following 3x layers of indirection is a common workflow:

$ nomad status | grep pgbouncer
pgbouncer                              service  50        running
$ nomad status pgbouncer
ID          = pgbouncer
Name        = pgbouncer
Type        = service
Priority    = 50
Datacenters = dc1
Status      = running
Periodic    = false

Summary
Task Group  Queued  Starting  Running  Failed  Complete  Lost
txn         0       0         3        0       0         0

Allocations
ID        Eval ID   Node ID   Task Group  Desired  Status   Created At
4e5c3530  e4d96cda  59286bb1  txn         run      running  01/10/17 20:36:38 UTC
0c943c1f  3c7b5e32  5303435d  txn         run      running  01/10/17 20:29:22 UTC
6bf8e1d6  a2a98867  e1f6dc5d  txn         run      running  01/10/17 20:02:41 UTC
$ nomad node-status 59286bb1 | grep Name
Name   = nomad-client-192-168-83-143
$ ssh nomad-client-192-168-83-143.node.consul

With this PR (and an environment running Consul 0.7.4 or newer) both Consul and Nomad will use the same Node ID if the OS presents a system-level UUID. As a result, it is now possible to use the node-id exposed via nomad status ${job_name} in service discovery, which enables the following workflow:

$ nomad status pgbouncer | grep running
Status      = running
4e5c3530  e4d96cda  59286bb1  txn         run      running  01/10/17 20:36:38 UTC
0c943c1f  3c7b5e32  5303435d  txn         run      running  01/10/17 20:29:22 UTC
6bf8e1d6  a2a98867  e1f6dc5d  txn         run      running  01/10/17 20:02:41 UTC
$ ssh 59286bb1.node.consul
$ ssh 5303435d.node.consul
$ ssh e1f6dc5d.node.consul

Updating resolv.conf(5)'s search parameter is left as an exercise to the reader.

The updates to shirou/gopsutil and friends remove a few more cgo dependencies.

@github-actions
Copy link

github-actions bot commented Apr 6, 2023

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 6, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants