During usability testing, the user was trying different invocations of cbft, and running into address binding issues (like firewall issues) on linux...
./cbft
=> cbft registered as localhost:8095
./cbft -bindHttp 0.0.0.0:8095
=> cbft registered as 0.0.0.0:8095
./cbft -bindHttp 10.5.3.32
=> cbft registered as 10.5.3.32:8095
And then the user visited the web UI -> Nodes screen and saw 3 incorrect entries, where the expectation is there should be only one entry.
The proposed solution is that the 2nd & 3rd invocations of cbft should have failed to start on an "UUID for node already taken" kind of error message, ideally with helpful info on how to clean up a prior, incorrect cbft registration.
During usability testing, the user was trying different invocations of cbft, and running into address binding issues (like firewall issues) on linux...
./cbft => cbft registered as localhost:8095 ./cbft -bindHttp 0.0.0.0:8095 => cbft registered as 0.0.0.0:8095 ./cbft -bindHttp 10.5.3.32 => cbft registered as 10.5.3.32:8095
And then the user visited the web UI -> Nodes screen and saw 3 incorrect entries, where the expectation is there should be only one entry.
The proposed solution is that the 2nd & 3rd invocations of cbft should have failed to start on an "UUID for node already taken" kind of error message, ideally with helpful info on how to clean up a prior, incorrect cbft registration.