Bug 536015 (RHQ-40)

Summary: usability: (agent-server comm setup) interactive agent setup prompts in wrong order
Product: [Other] RHQ Project Reporter: Greg Hinkle <ghinkle>
Component: AgentAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 0.1CC: asantos, ccrouch, jshaughn
Target Milestone: ---Keywords: FutureFeature, Improvement
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-40
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-12 15:39:33 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Greg Hinkle 2008-03-06 06:01:00 EST
The agent setup commands are done in the wrong order. It should ask for the server address and port before asking for the agent address and port. After taking the server adress + port it should make an unauthenticated ping command to the server, the server should return the calling address and that should be used as the default agent ip in the agent address prompt. (It would also obviously give you an immediate error if it couldn't reach the server)
Comment 1 John Mazzitelli 2008-03-07 12:52:10 EST
see forum thread: http://forums.rhq-project.org/viewtopic.php?f=5&t=23
Comment 2 Red Hat Bugzilla 2009-11-10 16:08:43 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-40
Comment 3 Joseph Marques 2010-08-09 00:46:51 EDT
fixing this will go a long way towards the intuitiveness of the agent-server 
comm setup.  over the years, since HA has been released, we've seen several 
customers as well as community members stumble over this.  the root of the 
problem is caused by the fact that the server has two bind IP addresses - one 
which the server itself runs on, and another used for agent communications.  if 
the agent pings the server and gets a response, the IP address the response 
came on should be the one used for remote communications, and the interactive 
setup prompt should use that value by default.  this will not only save users 
time in the future from having to enter the IP address manually, but should cut 
down on the number of cases when users misconfigure this due to the dual-bind 
nature of the server.