administration > templates

Joseph Marques jmarques at redhat.com
Tue Oct 26 17:17:29 UTC 2010


  On 10/23/2010 12:05 PM, John Mazzitelli wrote:
> ...
> 1) the new Administration>Templates GWT based GUI (it shows essentially
> the same data as the old jsp templates page, but in scrollable lists
> views - the servers are in a tree view with the tree nodes collapsible
> under all top level servers).
> ...
> Anyone knowledgeable in the way the old jsp pages work for alert
> templates, please look at this new stuff to make sure I didn't forget
> anything.
Yeah, the type hierarchy certainly complicates the issue.  There are 
three main "buckets" of types that I can see:

1) types with multiple parent(Type)s
2) types with precisely one parent(Type)
3) types with no parent(Type)s, which is a special case of #1 because it 
implies all possible parent types

I've installed all plugins available in the RHQ repo, then did a quick 
analysis (see attachment) to help those reading this thread get familiar 
with these various relationships using actual types.

Although these 3 buckets naturally prevent a single resource type tree 
from being the main entry point into administration>templates, we 
shouldn't force the user to understand these different buckets / 
relationships when exploring the templates page to find the type they 
want to create a template against.

In the old JSP pages, although these 3 buckets did exist, they were all 
auto-expanded by default.  This allowed the user to ctrl+F (find), 
iterate through the results, and find the name of the type they were 
looking for.  The new UI takes away that ability because the server type 
trees are collapsed, making it more difficult for users to quickly find 
the type they are looking for.  For instance, I can no longer ctrl+F, 
enter "jvm" and find the various jvm types to create alerts against.

My suggestion would be to use a single, flat list view with one or more 
search filters at the top (name filter, category filter, etc).  The 
immediate result (assuming the default sort is alphabetical on the name) 
is that the row items might look like:

Connector
Connector
Embedded Tomcat Server
Embedded Tomcat Server

Here, the "Embedded Tomcat Server" rows are the names of a resource 
types that exists as children servers under two different "JBossAS 
Server" resource types, one defined by the JBossAS plugin, the other by 
the JBossAS5 plugin.  Likewise, the "Connector" rows are the names of 
the service resource types that exists under the parent "Embedded Tomcat 
Server", but since there are two distinct parent(Type)s, there are two 
distinct children with the same name.

Although this seems like an issue on the surface, we do have experience 
in dealing with problems of this kind -- disambiguation.  If we simply 
augment the list to show disambiguated resource type info, then a 
single, flat list view should suffice.  Users can quickly search it (by 
type name, by type category, etc), and for types that have name 
duplicates the corresponding hierarchy is there to disambiguate:

Connector : Embedded Tomcat Server > JBossAS Server (JBossAS)
Connector : Embedded Tomcat Server > JBossAS Server (JBossAS5)
Embedded Tomcat Server : JBossAS Server (JBossAS)
Embedded Tomcat Server : JBossAS Server (JBossAS5)

Then, for the special case where resources either don't have a parent 
(typically platforms [which are logical root types] and servers [which 
are generally discoverable under any platform]), we wouldn't even need 
to add disambiguation data because they are already logical singleton 
types.  Below is a larger snapshot of the single, flat list view concept 
with a blend of platforms, platform-services, top-level servers, nested 
servers, and services all in one:

AIX
Ant Bundle Handlers
Cobbler
Connector : Embedded Tomcat Server > JBossAS Server (JBossAS)
Connector : Embedded Tomcat Server > JBossAS Server (JBossAS5)
CPU
Embedded Tomcat Server : JBossAS Server (JBossAS)
Embedded Tomcat Server : JBossAS Server (JBossAS5)
File System
File Template Bundle Handler
FreeBSD
Hosts File
HP-UX
JBossAS Server (JBossAS)
JBossAS Server (JBossAS5)
Linux
Mac OS X
Network Adapter
Process
Solaris
Sudoers
Windows

Last but not least, we should have a checkbox at the top of the table to 
filter by "utilized types".  Utilized types are the types in the system 
that have at least one resource instance in inventory.  This (often 
dramatically) reduces the number of displayed types.  For instance, if 
I'm a RHEL/EAP shop and haven't yet upgraded to EAP5, my utilized type 
list would look like:

Ant Bundle Handlers
Cobbler
Connector : Embedded Tomcat Server > JBossAS Server (JBossAS)
CPU
Embedded Tomcat Server : JBossAS Server (JBossAS)
File System
File Template Bundle Handler
Hosts File
JBossAS Server (JBossAS)
Linux
Network Adapter
Process
Sudoers

The disambiguation information is still there (it doesn't hurt to show 
it, even when it's unnecessary), but the results are a lot more focused 
because resource types the user may never need are suppressed.

Thoughts?

-joseph

PS - The "HTTPService" and "PingService" are not listed anywhere in any 
of the 3 existing buckets, either on the old JSP pages or the new 
GWT-based, scrollable list views.  Although they are logically 
platform-services, they were defined in a separate NetworkServices 
plugin (not defined by the platform plugin).  The single, flat view list 
concept would not treat these edge cases any differently, and would 
display them in the results without issue.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: resource-type-summary.txt
Url: https://fedorahosted.org/pipermail/rhq-devel/attachments/20101026/a1146e56/attachment.txt 


More information about the rhq-devel mailing list