Plugin Descriptor Changes

<drift name="foo">
  <basedir>...</basedir>
  <interval>300000</interval>
  <includes>
    <include path="a..." pattern="a..." />
    <include path="b..." pattern="b..." />
   </includes>
   <excludes>
     <exclude path="a..." pattern="a..." />
     <exclude path="b..." pattern="b..." />
   </excludes>
</drift>

Mazz:

Under the covers, we build a Configuration object with those properties, but the plugin author should not be forced to understand the underlying configuration properties. The plugin container should create a domain object that encapsulates these config properties and provide a strongly typed API like: DriftConfigiration.getBaseDirectory() and DriftConfiguration.getIncludes() ...

<drift name="foo">
  <basedir>...</basedir>
  <interval>300000</interval>
  <filters>
    <include path="a..." pattern="a..." />
    <include path="b..." pattern="b..." />
    <exclude path="a..." pattern="a..." />
    <exclude path="b..." pattern="b..." />
  </filters>
</drift>

In order for a resource type to support drift management it is necessary  to specify at least one <drift> element. Note that you are not required to specify any of the child elements. The preceding example illustrates the allowable child elements, though none of them are required.

Each <drift> element must have a unique name. We might for example have something like <drift name="webapps"> and <drift name="EAP server configuration"> where the former specifies drift management only for web apps whereas the latter specifies drift management for files under JBOSS_HOME/bin and JBOSS_HOME/server/default/conf (assuming we are running the default server configuration).

TODO If only one <drift> is declared, should the name attribute still be required? We could generate a default value alleviating the need to add the extra mark up.

basedir

Specifies the base or root directory from which snapshots will be taken.

Specifying the base directory in the plugin descriptor does not make a whole lot of sense the location of a resource is not know until runtime when it is discovered. But it does make sense to say you want the base directory set to the root directory of your Tomcat installation if for example you are managing drift for Tomcat servers. See the next section, Using Lazy Evaluation for more information on how to do this.

includes

Allows you to specify zero or more inclusion filters. If inclusion filters are specified, then only paths matching the filters will be included in the snapshot.

excludes

Allows you to specify zero or more exclusion filters. If exclusion filters are specified, then any paths matching the filters will be excluded in the snapshot.

interval

Allows you to specify in milliseconds how frequently drift monitoring is performed.

Generally a user should be able to enable drift monitoring for a resource without having to having to make additional configuration changes. The plugin should provide a sensible set of defaults. This can be accomplished with the properties described in this section.

<drift name="Default Drift Configurtion">
  <basedir>${homeDir}</basedir>
</drift>

SnapshotFacet

public interface SnapshotFacet {
    DriftConfiguration getSnapshotConfiguration(Configuration pluginConfig DriftConfiguration driftConfig);
}

SnapshotFacet is implemented by the discovery component. Immediately after the plugin container invokes the discovery component's discoverResources method, it will invoke getSnapshotConfiguration for each discovered resource and for each drift configuration declared in the plugin descriptor. If two drift configurations are declared in the plugin descriptor (i.e., <drift name="foo"/> and <drift name="bar"/>), then getSnapshotConfiguration will be called twice. discoverResources returns a set of DiscoveredResourceDetails. Each DiscoveredResourceDetails object contains a plugin configuration object. That plugin configuration object is passed as the pluginConfig argument to getSnapshotConfiguration. That same plugin configuration will be used across multiple invocations of getSnapshotConfiguration.

The driftConfig argument contains properties that correspond to the child elements of <drift>. If any defaults are specified in the plugin descriptor, the corresponding properties in the driftConfig object will be initialized to those default values.

Associate Snapshot with Multiple Resources

There may be times when you want to use a shared, common baseline snapshot among multiple resources. A good example of this is performing drift management on a cluster of EAP servers where you want to manage drift between those servers. In other words, you want to monitor for changes so that you know if/how those EAP servers differ.

Import Snapshot into RHQ

Uploading Snapshots

The server needs to provide an API for the agent to upload snapshots. Both the data and meta data files for snapshots can be very large.

// This is bad! We do not want to load entire files
// into memory.
void uploadFile(String file);

// This is also bad! We do not want to load entire
// files into memory.
void uploadFile(byte[] file);

// This is good! Consuming the file as a stream
// avoids loading the entire file into memory.
void uploadFile(InputStream file);

Manage Persistence with Server Plugins

A one size fits all approach is not going to be an adequate solution for persisting snapshots. A number of things will impact the performance and reliability characteristics persistence store. Some of these things include:

• The amount of snapshot data being stored in terms of physical storage

• The number of snapshots and snapshot meta data being stored

• The frequency at which agents upload snapshots to the RHQ server

• The frequency of writes to the persistence store

The RHQ database may be a perfectly acceptable persistence store in many situations, but it may be inadequate in situations where a high write throughput to the database is needed. We already see performance limitations in this area with metrics. This is why we need a pluggable strategy. Snapshot persistence will be managed by server plugins. We can provide a default implementation that uses the RHQ database. Other plugins could be developed to utilize other persistence stores such as,

• A relational database (but separate from the RHQ database)

• Amazon S3

• Document-oriented databases like CouchDB or MongoDB 

• Column-oriented databases like HBase or Cassandra 

• Content management system like ModeShape

Data Model

Note that these schema changes are for a default server plugin implementation.