(05:48:27 PM) mazz: jshaughnessy: question - I do a dbsetup-upgrade, how does the ancestry column get populated for already existing resources in my inventory ?
(08:27:56 PM) ips: mazz - good question. doing a quick scan of the code, it doesn't look like it would
(08:28:25 PM) ips: a good way might be to just recurse the entire inventory at server startup
(08:29:13 PM) ips: and for each resource do: if (res.getAncestry() == null) { res.updateAncestryForResource(); }

(08:30:34 PM)
ips: i think we should make the two delims used in the ancestry string completely different characters from each other
(08:30:46 PM) ips: that would make the strings more human-readable
(08:31:29 PM) ips: which is useful when looking at the field's value while attached with a debugger or in dbvis etc.
(08:32:02 PM) ips: eg:
(08:32:52 PM) ips: public static final String ANCESTRY_ENTRY_DELIM = "|||"; // delimiter separating entry fields
(08:32:52 PM) ips: public static final String ANCESTRY_DELIM = ":::"; // delimiter separating ancestry entries

On 03/08/2011 02:38 PM, Jay Shaughnessy wrote:
The first pass has just been pushed to the git repo.

THIS INCLUDES A DB UPGRADE to schema version 2.106.   The upgrade adds 
the rhq_resource.ancestry field and also populates it for existing 
inventory.

Other comments inline...


On 3/8/2011 5:10 AM, Lukas Krejci wrote:
On Monday, March 07, 2011 19:50:36 Jay Shaughnessy wrote:
On 3/7/2011 11:49 AM, Charles Crouch wrote:
Looks good. Some thoughts/questions...

1)So an example value in a resource_ancestry column for a Datasource
resource could be?:

10100_:_10101_:_JBoss EAP_::_10010_:_10011_:_mylaptop.test.com
That looks feasible.

2) Plugins can't change existing resource names after resource creation
right, even after an upgrade? So that shouldn't be a problem

3) I know it will be take some crazy set of circumstances to hit the 4k
limit, but can we make sure that if we do hit the limit, that we just
stop writing at the highest complete ancestry level, and don't end up
with "....10100_:_101"
alright, I'll add that check.

4) Will this new approach make any changes from RHQ3 in how the displayed
resource's names actually look? IIRC the displayed resource names change
right now based on what other resources are in the list, we basically do
just enough to ensure uniqueness? i.e. we don't show the full resource
hierarchy for every resource in every list view. Will this remain the
same?
No, the approach is different. At least initially.  In RHQ3 we typically
saw a "Resource" column.  The value in that column was different
depending on the resources in the list. The resource name was always
shown.  The type name was added when multiple resources for the same
type were present.
multiple resources of the same name

The plugin name was added to that if the type name
could come from multiple plugins.  Perhaps more was done, I'm not sure.
Additionally, the "Location" column contained ancestry information and
also could have varying detail.

In my opinion the RHQ3 approach has some drawbacks.  The varying detail
in the "Resource" and "Location" columns is visually disorienting and
somewhat hard to understand.  Also, It can be quite verbose in the
column layout.

In RHQ4, at least initially, we've gone back to having a simple "Name"
column with the resource name wrapped in a navigable link.  The
"Location" field is now "Ancestry" and shows the parental ancestry, by
resource name, also wrapped in links.  Furthermore, we're integrating
hover in various ways.  In the inventory lists you can hover over the
"Ancestry" value and also see the parental *Type* ancestry.

One of the goals of the original disambiguation was for the user to be able to
distinguish between the 5 "localhost" resources in the result lists at a
glance.
For example apache, postfix, samba, jboss-as(5) and maybe even others can be
called "localhost:port" and have the same ancestry (i.e. the platform they're
installed on). The user will only be able to distinguish these on hover unless
they remember what port each of them is available on, which I am not sure is
ideal.

Yes, in RHQ3 the contents of the column could vary in the level of detail but
each element of that "detail" had slightly different visuals (type and plugin
names in italic, resource name in bold with a link) to "guide" the eyes.

I'm not saying that that is better than what you propose, I'm just trying to
put the two approaches next to each other so that we can pick and choose the
good things from either.
That's good information.  I like the intent of what was done.  I think 
we can probably tweak things to arrive somewhere in between what's there 
now and what was in RHQ3.  Hopefully now that it's getting rolled out 
more folks will contribute their feedback.

This is where things stand right now, four days in.  Having said the
above, taking the RHQ3 approach, or maybe something in between, is
probably doable (paging maybe a problem?).  Given a result set of
resources it's possible to process things in various ways, client-side
for GWT.

Although not done yet, we'll need to provide the CLI with some utility
to decode the ancestry values.

Also we're going to need some utility in the server code itself so that
serverside plugins can use this. Alert::Email I think can insert the ancestry
info in the emails.

Thanks very much
Charles

----- Original Message -----

The proposed changes for disambiguation in RHQ4 have an initial design
section in the following wiki page:


http://www.rhq-project.org/display/RHQ/Disambiguation+API#Disambiguation
API-RHQ4Changes

Please review and question. Thanks,

Jay

_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel

_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel


-- 
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer@redhat.com