Bug 535433 (RHQ-2129)

svn rev4035 - a SnapshotReport utility is checked in. It can zip up a set of config files and log files into a single compressed zip file.

we still need a plugin API / facet so the UI can send the snapshot request down to the agent and have the agent stream up the zip file. this checkin only includes a utility that plugins can use to generate the zip file.

svn rev4036 adds the ability to tell the utility about some additional files to include in the snapshot.

svn rev4040 - can now take a snapshot of the agent from the server. only control.jsp can call it, need a UI page to do this. configuration is stored in plugin config to match how events and everything else works.

jopr svn rev721 adds support for this facet to the jboss-as plugin. i ran a quick test and it worked.

Found one issue with SnapshotReport object - it needs to crawl down subdirectories so it can get all content below the logs, conf and data directories. Need to figure out if I can use the regex's to limit what subdirectories it captures.

would like to add a new boolean config to SnapshotReport (and hence the resources' plugin config) - add a "recursive" boolean - if true, traverse down all subdirectories under config/log/data/additional directories. There should be 4 recursive props - one per config/log/data/additional dir.

rhq svn rev4041 adds the ability to recurse down subdirectories

jopr svn rev 722 adds the recurse feature and additional files snapshotting to the jboss-as plugin

implemented a prototype. This can be used in the grander design of a "support subsystem".

This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2129

subject was:

be able to take snapshots of a resource's log files/config files/others and upload to server

An issue with the work up to this point is that the SupportFacet generates no meta-data for the resource type. In other words, the plugin descriptor does not in any way declare anything related to the feature, and the db does not reflect any obvious entries to make support facet discovery obvious.  Server side detection of facet implementation is needed for (potential) Tab/Menu/Icon activation (and perspective FacetActivators).

As a temporary workaround for server side discovery we take advantage of the fact that resource types offering support snapshots define specific plugin config properties (like "snapshotConfigEnabled").  This is not a good way to perform the discovery but works for now.

A better way will be to drive off of real meta-data generated by declarations in the plugin descriptor.  The most simple addition would be a simple tag, something like:

<support>

On the ResourceType (Server or Service) descriptor.

I implemented this but it was decided to not add this change to the codebase. We think it will be better to wait until we have a chance to fully design an initial support subsystem.  We may not want to tie ourselves just yet to that specific tag.

I will try and generate a git patch with the changes, just as a historical reference to what it takes to make the change to add the <support> tag.

Created attachment 405598 [details]
The git diff of changes proposed for adding <support> tag

The git diff of changes proposed for adding <support> tag to plugin descriptor and driving supportfacet detection off of a flag on ResourceType.

mazz, thoughts on jshaughn's attachment?

john sanda is looking at other things around this area (drift management). We are going to hold off on this support subsystem for a bit.