Created attachment 766029 [details] log from host-deploy Description of problem: Although there is host in cluster, it is possible to add the same host if we use hostname instead of IP address (and vice versa) Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Add host using its hostname 2. Add the same host using its IP adress Actual results: The host is added, only status install failed, but it is still possible to activate Expected results: The portal should not accept a host that is already in use Additional info: log from host-deploy added as attachment
Just for the record, it is almost impossible to know if host is the same host as host can have multiple interfaces and names. *** This bug has been marked as a duplicate of bug 964967 ***
isn't the uuid of the host supposed to fail adding/activating it?
(In reply to Itamar Heim from comment #2) > isn't the uuid of the host supposed to fail adding/activating it? When a host is added we cannot know what it is uuid, as uuid requires a logic within engine which is duplicate to host deploy, including creating vdsm id and so on, this was removed from engine in order to stop maintaining distributed duplicated algorithms throughout the project, and the past requirement to support complex dependency relationship matrix of components/versions. The duplicate uuid is discovered during host deploy reported to the engine to allow validation before performing the actual installation. The result is host is added, a message of duplicate uuid in event log and install failed status. To provide earlier validation we added vdsm command to report uuid (bug#964967), that if found will be used during canDoAction of AddVdsCommand. This method does not resolve all cases, for example if host was added into engine, then completely re-installed, then re-deployed using different address, but the above safe guard will always discover that. A better implementation compared to performing two ssh sessions (one at canDoAction and the other for host deploy) is to start the host deploy process at the canDoAction, while testing requirements at customization stage, then pass the object with the session to the actual action body. But it was way to complex with current engine design, as we split between AddVdsCommand and InstallVdsCommand, I guess because of the lack of proper development environment which required developers to hack the deploy in order to have a working system.
OK, it took me a while to understand the problem description. The problem is not that the host cannot be added, this was expected, the problem is that there is no validation during activation that the host has valid uuid. My bad. Thanks for the report!
commit fcc15aa081631d08162482cf00ff2f3fa0305a9e Author: Alon Bar-Lev <alonbl> Date: Fri Jul 5 23:59:49 2013 +0300 bll: do not allow host activation with no unique id partial installation of host for various of reasons will leave a host with no uuid. these hosts should not be allowed to be activated. for developers, if the InstallVds option is false, this validation will be disabled. Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=978906 Change-Id: I9a15416ae21c2371ebfb12cecb1551b73c98d88f Signed-off-by: Alon Bar-Lev <alonbl>
Just for the record, the correct solution would have been to avoid activation if the host is in install failed. However, there were too many cases in the past in which install failed for some reasons which was false positive. If we are ready for prime time, we should apply this solution.
verified on is6
Closing - RHEV 3.3 Released