We are implementing a CMDB and want to link information to machines in juju.
For this purpose, I need a stable way to have a unique identifier (database key) for a juju-machines. Ideally the machines information would be available in the juju controller database.
If there is a “machine key”, I could use that to database join with data from of our other collected information.
What I cannot use as universal machine identity
These do not survive cloning, provider differences, or match between Juju and your external system:
| Candidate | Problem |
|---|---|
| Juju instance-id | Only exists when Juju is managing the machine; LXC clones produce new names |
| LXD container name | Only for LXC; not persistent outside LXD |
| Nonce (agent.conf) | Only used during provisioning; random; never reused |
| IP address, DNS name | Not stable or unique |
| MAC address | Reassigned on reboot, clone, bridge changes |
| Hostname | User can change it; Juju changes it too |
| EC2 instance-id | Valid only in EC2, not on LXC or bare metal |
| Node UUID (dmidecode) | Not accessible inside LXC, and can be duplicated in VMs |
I had some hopes for the The instance_id ? , but (source: chatGPT):
This is the machine’s provider ID, coming from:
- LXD → container name
- EC2 → instance ID
- MAAS → node system ID
- Manual → generated “manual::UUID”
- VMware → VM UUID
This is stable only as long as the provider persists, but its not unique for manual clouds for example.
Unique in its cloud provider
Not universal across providers
Not accessible from inside the machine without Juju
Not stable when machines are recycled or rebuilt
At this point - the only option I seem to be able to use “fairly” consistent would be the hostname or dns-name as given from “juju show-machine”.
Is there anyone that would have a better idea of a “unique machine identifier” which also is possible to extract outside of juju?