Bug 1070242 - (JON3-30, PRODMGT-542) Tracker: Provide enterprise version and support of remote agent install feature from RHQ
Tracker: Provide enterprise version and support of remote agent install featu...
Status: CLOSED CURRENTRELEASE
Product: JBoss Operations Network
Classification: JBoss
Component: Agent (Show other bugs)
JON 3.3.0
Unspecified Unspecified
unspecified Severity unspecified
: CR01
: JON 3.3.0
Assigned To: Jay Shaughnessy
Mike Foley
:
Depends On: 1148403 1090448 1090453 1090462 1090476 1090829 1091015 1091172 1091339 1091394 1091409 1128772 1128779 1128782 1129290 1129294 1130162 1131495 1132051 1144467 1151217
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-26 08:31 EST by Heiko W. Rupp
Modified: 2015-05-28 10:09 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-12-11 09:01:52 EST
Type: Feature Request
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screen mock-up #1 (208.34 KB, image/jpeg)
2014-03-31 09:56 EDT, John Mazzitelli
no flags Details
screen mock-up #2 (204.56 KB, image/jpeg)
2014-03-31 09:56 EDT, John Mazzitelli
no flags Details
screen mock-up #3 (205.87 KB, image/jpeg)
2014-03-31 09:57 EDT, John Mazzitelli
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JON3-30 Major Resolved Provide enterprise version and support of remote agent install feature from RHQ [PRODMGT-542] 2016-09-14 22:19 EDT

  None (edit)
Description Heiko W. Rupp 2014-02-26 08:31:11 EST
Provide capability to perform remote agent install on a platform though SSH connection.
Comment 1 John Mazzitelli 2014-03-17 13:42:11 EDT
Since I originally completed this RHQ feature, I can re-test it and make sure its ready for includsion in the product.
Comment 2 John Mazzitelli 2014-03-18 16:41:34 EDT
git commit to master: 9f398847849dd5b9f7f94f66719bd95663caa096

remote installation of agent is now possible from Admin>RemoteAgentInstall. You provide hostname, ssh port, and user credentials and via jsch you can install, start and stop agent as well as get the status of an installed agent (is it running?) and even try to find where an agent might be installed.
Comment 3 John Mazzitelli 2014-03-26 14:12:02 EDT
There are additional features that have been requested, so I can't close this as MODIFIED yet. The following is the original requirements:

---

It is expected that the remote agent operation would request credentials or use a system wide default set of credentials set by an administrator and obfuscated from all users. The credentials would be used to access the remote target system.

The user would also be prompted for the target host and optionally an alternate port number if not using the default SSH port.

The user should be asked for the destination path for where the agent is to be installed and whether an existing agent installation should be deleted if it already exists. Additionally, an optional agent-configuration.xml file or URL may be specified to provide custom configuration. Otherwise, a generated agent-configuration.xml should be used that specifies the minimum defaults along with the target JON server configuration.

The commands and payload should be secured to ensure this capability can not be used to push out other things to the agent such as a trojan.

When the process is done, the agent is started and the server should report whether the process was successful and that the agent's platform has been discovered and is available in the discovery queue.

The remote operation should also provide a function that wipes the agent installation after shutting down the relevant agent and then de-registering it and removing its platform from inventory.
Comment 4 John Mazzitelli 2014-03-26 14:40:51 EDT
These are things we still need:

1) A system wide set of credentials. We'd put these in System Settings, and obfuscate the password. This would mean the user/pass credentials have to be the same across all machines where the agents are to be installed (so, for example, someone would need to create a "rhq" user that has SSH access to all machines).

As a supplement, we could look to see if we can provide a way to support key authentication rather than providing password credentials. But I don't see that as a hard requirement here as written. It would be a "nice to have".

2) The user should be asked ,.. whether an existing agent installation should be deleted if it already exists. Right now we disallowe the install to continue if an agent exists.

3) Additionally, an optional agent-configuration.xml file or URL may be specified to provide custom configuration. We do not provide a way to override the config.xml.

It would also be nice to be able to specify custom RHQ_AGENT_ADDITIONAL_JAVA_OPTS values that we could then store in rhq-agent-env.sh so the agent will use those at startup. But this is not required and thus is a "nice to have."

4) The remote operation should also provide a function that wipes the agent installation after shutting down the relevant agent and then de-registering it and removing its platform from inventory. This would require a new button "uninstall" to be provided that does this.
Comment 7 John Mazzitelli 2014-03-31 09:56:01 EDT
Some UI ideas from UXD folks:

* All of this functionality should move to the "Agents" area of the Admin tab, instead of adding a new section to that tab.
* New should be added as an action to the bottom of the table that allows you to add a new agent to a host
* Start/Stop functionality should hang off of the table as well, enabling you to start and stop any agent in the list.  Potentially we should add a status column to this list to show wether the agent is running or stopped, or we could re-use the 'Last availability report" to show it is stopped.
* New should bring you to a modal where you enter the form. 
* Validation of the install shows in this modal as well, and the user can return to the table to see their new agent at any time as well.

I will attach the mock ups.
Comment 8 John Mazzitelli 2014-03-31 09:56:37 EDT
Created attachment 880754 [details]
screen mock-up #1
Comment 9 John Mazzitelli 2014-03-31 09:56:58 EDT
Created attachment 880755 [details]
screen mock-up #2
Comment 10 John Mazzitelli 2014-03-31 09:57:17 EDT
Created attachment 880756 [details]
screen mock-up #3
Comment 11 John Mazzitelli 2014-04-14 14:51:31 EDT
this has been git committed to master: 38b17119771a5788b0d0fa389770228cdefafbd8
Comment 13 JBoss JIRA Server 2014-04-22 09:18:55 EDT
Heiko Rupp <hrupp@redhat.com> updated the status of jira JON3-30 to Resolved
Comment 17 Simeon Pinder 2014-07-31 11:52:33 EDT
Moving to ON_QA as available to test with brew build of DR01: https://brewweb.devel.redhat.com//buildinfo?buildID=373993
Comment 20 JBoss JIRA Server 2014-08-15 18:44:51 EDT
mfoley user <mfoley@redhat.com> updated the status of jira JON3-30 to Reopened
Comment 24 Simeon Pinder 2014-09-29 04:12:51 EDT
Moving into ER05 as didn't make the ER04 cut.
Comment 26 Jay Shaughnessy 2014-10-23 09:19:06 EDT
Moving to VERIFIED, dev work complete and verified (in ER05 or earlier), 2 blocking BZs are doc only.
Comment 27 JBoss JIRA Server 2015-05-28 10:09:40 EDT
John Mazzitelli <mazz@redhat.com> updated the status of jira JON3-30 to Resolved

Note You need to log in before you can comment on or make changes to this bug.