Bug 535941 (RHQ-343)

Summary:	Remote Client - CLI
Product:	[Other] RHQ Project	Reporter:	Ian Springer <ian.springer>
Component:	CLI	Assignee:	Simeon Pinder <spinder>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	high
Version:	unspecified	CC:	ccrouch, cwelton
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	All
URL:	http://jira.rhq-project.org/browse/RHQ-343
Whiteboard:
Fixed In Version:	1.3	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-10-07 03:28:18 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	535437, 535438, 535464, 535465, 535466, 535515, 535519, 535613
Bug Blocks:

Description Ian Springer 2008-04-21 14:38:00 UTC

*** Update:
The design for this is here: http://jopr.org/confluence/display/RHQ/Design-CLI

The CLI will be a Java Remote Client utilizing the Remote API defined here: http://jopr.org/confluence/display/RHQ/Design-API.  It will be backed by jboss remoting.
***


This would allow various RHQ functions to be performed in a scripted and audited manner.

Note: This warrants some discussion in the forums, because it could be argued that a CLI is not necessary if the RHQ GUI can be enhanced to:

1) support doing all actions on a compatible group (currently, some subsystems, such as Configuration and Packages, do not support compat groups)
2) support scheduling of various actions (e.g. group plugin config updates to change JNP passwords across a group of AS servers)
3) log all user-initiated actions to the log, and ideally also to a history table in the DB (for auditing purposes)

Comment 1 Ian Springer 2008-05-08 16:16:55 UTC

This is how we would implement the CLI:

1) duplicate the same kind of prompt command subsystem that the agent has, only put it in the server
2) create a SLSB with a remote interface with possibly a @WebService interface as well
3) the SLSB must have methods to a) log onto the server and return a Subject and b) take a Subject and a command or commands to execute
4) the SLSB returns the results of the command(s) executed
5) have a JSP page that accepts the input

For now, the cli commands will each make their own calls to the session bean layer to perform its job. It must accept data that a user can type into a keyboard, convert to domain objects as appropriate, process the command, and return the results (probably as a String that can be printed to the screen or logged in a file).

In the future, we can create a very small, lightweight CLI shell that simply logs into the server and passes whatever commands the user types to the server and returns the results back. All parsing of commands and execution happen on the server-side. The CLI shell will be very small - just pass text to the server and receive text back.

The Web Service interface means we could even have Perl, Python or other type of client submit requests to the server.

Comment 2 Red Hat Bugzilla 2009-11-10 21:07:23 UTC

This bug was previously known as http://jira.rhq-project.org/browse/RHQ-343
This bug is incorporated by RHQ-2125

Comment 3 Corey Welton 2010-10-07 03:28:18 UTC

closing this tracker