Bug 570839 - Provide ability to make the name of imported tomcat instances unique
Summary: Provide ability to make the name of imported tomcat instances unique
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Plugins
Version: unspecified
Hardware: All
OS: All
low
high vote
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact: Sunil Kondkar
URL:
Whiteboard:
Keywords: FutureFeature, Improvement
Depends On:
Blocks: jon24-naming jon30-bugs
TreeView+ depends on / blocked
 
Reported: 2010-03-05 15:27 UTC by Lami Akagwu
Modified: 2018-10-27 16:17 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2013-09-02 07:15:41 UTC


Attachments (Terms of Use)
enable remote update of a resource (4.75 KB, patch)
2010-03-05 16:36 UTC, Lukas Krejci
no flags Details | Diff
screenshot (176.18 KB, image/png)
2010-10-25 07:20 UTC, Rajan Timaniya
no flags Details
Screenshot_cli (123.19 KB, image/png)
2010-11-30 11:53 UTC, Sunil Kondkar
no flags Details

Description Lami Akagwu 2010-03-05 15:27:01 UTC
Description of problem:
In its current form, when you import multiple tomcat instances, there is no mechanism for distinguishing between the instances.
Each of the instance name typically appears as Tomcat(Port).
If all the ports are 8080, then there no way of telling which tomcat instance you are looking at.
While it may be possible to rename the resource name via the UI, it is not a viable solutions where you have several dozen resources or if you have to uninventory the resource and reimport.

Version-Release number of selected component (if applicable):
JON 2.3.x

How reproducible:
Always

Steps to Reproduce:
1. startup import multiple instances of tomcat where the port numbers are all 8080
2. import the resource via the JON GUI and the names of the resources appears as
Tomcat(8080)
Tomcat(8080)
.. ..
Tomcat(8080)


Additional info:
Possible implementation options

1. A configurable System parameter which can be read and appended to each instance to make the resource name unique e.g -DtomcatResourceIdentifier=Europe-zone-1-10.23.56.10
2. Provide  mechanism by which the resource name can be auto updated via the CLI; passing a parameter that should be appended to or replace the existing resource name

Comment 1 Lukas Krejci 2010-03-05 16:36:57 UTC
Created attachment 398076 [details]
enable remote update of a resource

Incidentally, progress is being made on the resource naming and presentation already.

In the next major version, the UI will be updated to present any kind of resource list (be it a search result or for example group membership list) in such a way that possible duplicate names will be resolved by specifying the parent path up to a point where it differs.

So in your reproduction steps, you won't see:
Tomcat(8080)
Tomcat(8080)
.. ..
Tomcat(8080)

but rather:
Tomcat(8080)   Platform1
Tomcat(8080)   Platform2
.. ..
Tomcat(8080)   PlatformN

As for the implementation options, I think the option 2. is a very useful extension. I am including a patch to add an ability for the CLI to update the resource remotely. 

For the sake of data consistency only the properties editable in the "General Properties" section in the UI are editable remotely using CLI (i.e. only the name, description and location of a resource).

Comment 2 Charles Crouch 2010-07-27 13:18:23 UTC
Someone looking for resource name changing ability
https://fedorahosted.org/pipermail/rhq-users/2010-July/000093.html

Comment 3 Charles Crouch 2010-08-05 04:12:04 UTC
Lets go ahead and apply this patch, *and* add tests that its works and has the appropriate security on it.

Comment 4 Lukas Krejci 2010-08-16 12:34:44 UTC
This functionality seems to have been added while addressing a separate issue by commit 38aa7252752eb905b84127662e0149f6d470ba7b.

Comment 5 Rajan Timaniya 2010-10-25 07:19:44 UTC
Tested on RHQ-Master build #500

Steps:
1) Installed RHQ server and 2 agents
2) Both agent has Tomcat 5.5 running on port 8899
3) Import all resource in RHQ server

Observation:
Tomcat server name shows as given below:
Tomcat (8899)    Platform-1
Tomcat (8899)    Platform-2

Tomcat server name can change from 'Summary' -> 'Overview' tab.

Comment 6 Rajan Timaniya 2010-10-25 07:20:27 UTC
Created attachment 455409 [details]
screenshot

Comment 7 Rajan Timaniya 2010-10-28 10:57:09 UTC
Hi Lukas, 

Require steps to test using CLI and what should be expected. Are tomcat servers discover with unique name or it will be fine if user can rename using UI or CLI?

Comment 8 Lukas Krejci 2010-11-10 14:53:42 UTC
Steps for CLI:

1) start up the cli using 

$CLI_HOME/bin/rhq-cli.sh

and do the following steps on in the CLI interface.
2) login rhqadmin rhqadmin localhost 7080
3) var r = ResourceManager.getResource(10001)
4) r.name = "updated"
5) ResourceManager.updateResource(r)
6) var r2 = ResourceManager.getResource(10001)
7) pretty.print(r2)

The result of the last statement should print the details of the resource with id 10001 which should have its name set to "updated".

Comment 9 Sunil Kondkar 2010-11-30 11:52:06 UTC
Verified on rhq-server-4.0.0-SNAPSHOT build#725.

Started the CLI and followed the steps as below:

rhqadmin@10.65.193.104:7080$ var r = ResourceManager.getResource(11794)

rhqadmin@10.65.193.104:7080$ r.name = "updated"
updated

rhqadmin@10.65.193.104:7080$ ResourceManager.updateResource(r)
Resource:
                         id: 11794
                       name: updated
                    version: 6.0.26.0
        currentAvailability: UP
               resourceType: Tomcat Server

rhqadmin@10.65.193.104:7080$ var r2 = ResourceManager.getResource(11794)

rhqadmin@10.65.193.104:7080$ pretty.print(r2)
Resource:
                         id: 11794
                       name: updated
                    version: 6.0.26.0
        currentAvailability: UP
               resourceType: Tomcat Server

 
This replaced the existing tomcat resource name to 'updated' as shown in attached screenshot.

Comment 10 Sunil Kondkar 2010-11-30 11:53:33 UTC
Created attachment 463703 [details]
Screenshot_cli

Comment 11 Heiko W. Rupp 2013-09-02 07:15:41 UTC
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.


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