Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Aperi R2 Extensibility Overview

Revision as of 13:00, 2 July 2007 by Dwolfe.us.ibm.com (Talk | contribs) (Overview)

Overview

Aperi Storage Manager leverages Equinox / OSGi technology and is built as a set of plugins. A number of extension points within Aperi's architecture enable developers to add functionality to Aperi's components by creating plugins. For example, the extensions for the IBM Storage Virtualization Controller (SVC) are discussed and a walk-through of the provided code extensions show how to add a vendor-specific storage device to Aperi.

The documents in this section of the wiki provide information about how to extend Aperi's v0.2/v0.3 functionality for the following components:

  • Data server: This component is the control point for product scheduling functions, configuration, event information, reporting, and GUI support. It coordinates communication and data collection with agents that gather storage demographics and populate the database with results.
  • Device server: This component discovers and gathers information for storage subsystems and SAN fabrics. It coordinates communication and data collection from agents that probe SAN fabrics.
  • Database (schema changes): A single database instance that serves as the repository for data collected by agents.
  • Agent: Agents gather host, application, and SAN fabric information and send this information to the Data server or Device server.

Each document includes descriptions of how to extend a component through a series of task descriptions. The information in these documents assumes knowledge of key Equinox / OSGi concepts (for example, plugins, extension points, etc.), as well as a basic understanding of Aperi’s architecture.

When planning a change or addition to an Aperi component, keep in mind the following:

  • Analyze the impact of the changes on the whole of Aperi.
  • Submit a change request to the component design team.
  • Test the change or addition by make an overall build with all the changes to ensure nothing breaks.
  • Send out a note to the aperi-dev mailing list highlighting the change.

As with all software projects, Aperi will evolve over time. These pages should be viewed as living documents that will change in response to the needs of developers looking to build on the Aperi platform. Please feel free to share any questions, comments, and concerns on either the Aperi Development mailing list (https://dev.eclipse.org/mailman/listinfo/aperi-dev) or the Aperi newsgroup (http://www.eclipse.org/newsgroups/index_project.php).

Any and all feedback is welcome.

Back: R2 API Documentation

Next: Aperi Data Server R2 Extensibility

Back to the top