Bug 915568

Summary: [RHSC] - After peer probing from cli, when trying to remove the host which was failed to install , the host which was peer probed also gets removed.
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: RamaKasturi <knarra>
Component: rhscAssignee: Kanagaraj <kmayilsa>
Status: CLOSED ERRATA QA Contact: RamaKasturi <knarra>
Severity: medium Docs Contact:
Priority: high    
Version: 2.1CC: dtsang, mmahoney, pprakash, rhs-bugs, sabose, sankarshan, shaines, ssampat
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-31 01:56:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Attaching engine log. none

Description RamaKasturi 2013-02-26 06:20:51 UTC
Created attachment 702633 [details]
Attaching engine log.

Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. add a host using hostname into the cluster using console.
2. go the CLI and do a peer probe of another host. 
3. go to console and click on import link on the general subtab .
4. It pops up with add servers screen.
5. You will see two hosts there, one is added through the console and one is peer probed host.
6. Set passwords for both and then click ok.
7. While it is getting installed the first one will fail saying that it is already part of cluster.
8. Once the host which has been peer probed from the CLI gets installed try to remove the one which was failed.
  
Actual results: It is removing the other host which was peer probed from the CLI.


Expected results: It should remove only the one which was failed to install.


Additional info:

Comment 2 Kanagaraj 2013-07-03 12:08:23 UTC
While importing, the hostname will be resolved to ipaddress and compared against the entries in the database. So its not be possible to arrive Step 5. 

It is possible that this bug was opened before the the below fix made into qa releases.

Upstream patch : http://gerrit.ovirt.org/#/c/12021/