-
Notifications
You must be signed in to change notification settings - Fork 2k
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
client id's are too similar #2534
Comments
I'm currently working around this by setting |
Hey @clinta, What are you suggesting? We have the deterministic ID through the host's UUID and give a way to have a random ID as you have discovered. |
I like the deterministic id, but I can't use it in our cluster because the first 8 characters of the system UUID are the same on all of the servers in our cluster. This is not unexpected, because the first bytes of the UUID are a timestamp of when the bios chip was burned, and we purchased a batch of identical hardware. Since the nomad interface only exposes the first 8 characters, this makes the interface unusable. Hasing the system UUID gives the best of both worlds. Deterministic, and randomly distributed so that the first 8 characters of the client-id will be unique. |
This PR takes the host ID and runs it through a hash so that it is well distributed. This makes it so that machines that report similar host IDs are easily distinguished. Instances of similar IDs occur on EC2 where the ID is prefixed and on motherboards created in the same batch. Fixes #2534
I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues. |
Nomad version
Nomad v0.5.6
Operating system and Environment details
Ubuntu 16.04
5 node cluster on identical physical servers.
Issue
The UUIDs for each node is very similar, and the first 8 characters, which are all that is displayed in the nomad, interface is identical.
Reproduction steps
Use hardware where the first 8 characters in
/sys/class/dmi/id/product_uuid
are identical. Since the first bytes of the UUID are a timestamp, I believe this can be expected on hardware who's bios chips were manufactured in the same batch and manufactured at nearly the same time.Possible fix
Hash the host UUID before using it to generate the nomad client-id. This will result in a random distribution of UUIDs where it will be unlikely to have a collision in the first 8 characters, while preserving the deterministic advantages of using the system UUID.
If this is a reasonable solution, I'd be happy to implement it and submit a PR.
The text was updated successfully, but these errors were encountered: