Currently we fail installation if we detect a duplicate vdsm id reported by host. This was ever since 3.0. With ovirt-host-deploy there is the option of enforcing vdsm id from engine, so we can detect this state and enforce random id. The problem is that if I add two addresses of the *SAME* host, we think that the second addition is a duplicate vdsm id, and generate our own. As a result we have two hosts up and running at engine side, polling the same vdsm, while its unique id is the random enforced one (the first can be either random or real bios uuid). Pros/Cons for that?
This keep be ask, I thought that a proper discussion is in order, so I can refer to it.
commit 47df0540d741bdc9380873309966d5c47fe665a1 Author: Alon Bar-Lev <alonbl> Date: Mon Dec 24 11:45:23 2012 +0200 host-deploy: enforce random vdsm id in case of duplicate CURRENT IMPLEMENTATION Fail installation if a duplicate vdsm id is reported by vdsm. PROBLEM IN CURRENT IMPLEMENTATION Manual intervention required: # uuidgen > /etc/vdsm/vdsm.id NEW IMPLEMENTATION Enforce random vdsm id when duplicate is reported. PROBLEM IN NEW IMPLEMENTATION A host can be added twice with different addresses/names, results in duplicate active hosts polling the same vdsm. Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=890022 Change-Id: Id448585b502cd53510526bc0a09bd7f9cd22230b Signed-off-by: Alon Bar-Lev <alonbl> http://gerrit.ovirt.org/10338
Test external tracker, should be nice but cannot add more than one in single commit?
you can have vdsm report the unique id in getVdsStats and verify it matches the engine's. so once a host will change its unique id you can detect this and move the "old host" to maint or something like that. if we are assuming vdsm will go down and up for such a change, using getVdsCaps will suffice, and no need to check it on each getVdsStats.
Question: does it worth the effort, or better to leave implementation as-is.
(In reply to comment #5) > Question: does it worth the effort, or better to leave implementation as-is. My initial thoughts where it's worth the effort, because when it happens it's just to confusing to figure out the problem. Don't forget duplicate IDs happen in some blade centers, meaning you have a bunch of identical hosts, not just two. A simple mistake may lead to adding the same host twice. On the other hand, if I understand correctly, this can't happen with RHEV-H hosts if RHEV-H registers to the manager. So for it to happen: 1. Must be RHEL hosts 2. Hosts must have same bios UUID 3. Hosts must have more then one IP to begin with. If the 3 above is accurate then you may leave the current implementation as is.
0. It can be RHEV-H. 3. Host can have single IP, but used as IP address, name, name.suffix, name.suffix.suffix. I think Andrew did not want to handle this as it is less than 0.5%...