ZenPacks provide extensions to the Zenoss platform in a number of ways, whether its additional monitoring, features or functionality.  The number of contributed ZenPacks is rapidly expanding, with new ones arriving all the time.  As the number of contributions has increased, it’s become increasingly apparent that we need to provide help for one another. Much as other open source projects have done, we need to help each other understand the contributions and share experiences.

We are introducing a framework for rating and categorizing ZenPacks so all Zenoss users can have greater confidence when extending their system.  Perhaps the most important aspect of a ZenPack is its quality. For example, we’d like to know that ZenPacks will install and uninstall easily.

The second most important attribute is knowing what a ZenPack actually does!  The ZenPack Framework addresses both quality and explanation.

ZenPack Quality

We’d like to give Zenoss users confidence in the quality of ZenPacks and help them know which ones can be used together.

To date the quality of ZenPacks has been largely anecdotal and is hard to determine without installation. We’d like to change that with two efforts:

• Providing a rating system so community members can simply share their experience with particular ZenPacks
• Identifying specific quality assurance tests

We’ve decided to create three basic categories to reflect ZenPack quality: Experimental, Testing and Stable.

• Experimental – in early stages of development or including risky code
• Community – hosted by Zenoss, will install and uninstall cleanly, some documentation
• Production-Ready – ready for production deployment, may be included with Zenoss Core and supported with Zenoss Enterprise

We encourage all ZenPack authors to evaluate their contributions against the detailed transition requirements and advance their contributions. Please contact community@zenoss.com if you have any questions.

Experimental

Experimental ZenPacks include those not yet hosted by Zenoss, found in the Zenoss forums or wiki and those submitted for approval but not yet listed on the ZenPack site. These “In the Wild” ZenPacks may not yet be categorized, lacking documentation or not be safe for installation in production environments. The ZenPacks may be developed by individuals or organizations, but no support is expected for them.

For a ZenPack to transition from Experimental to Community, the following steps must be taken:

• The ZenPack must not damage the installation and must install and uninstall cleanly.
• The primary documentation questions for ZenPacks must be answered, and the basic type of ZenPack identified.
• Installation prerequisites are clearly noted.
• Source must be available and the ZenPack can be built from it.
• To be hosted by Zenoss, the Contribution Form needs to be filled out by the author. This will allow Zenoss to relicense the ZenPack under the GPL, consider it for repackaging within Zenoss and allows the author to continue to contribute updates to any hosted ZenPack. ZenPacks may move to Community, but never to Production-Ready without this step.

Community

Most contributed ZenPacks will be classified in the Community category. This does not imply that they are unusable; it just indicates that they may not be completely documented or may be missing functionality.

To transition from Community to Production-Ready, the ZenPack needs to meet the following requirements:

• All documentation required for the category has been provided (see the categories below).
• There are no conflicts with existing Core or Enterprise functionality (ie. overriding existing templates).
• Installation prerequisites within Zenoss need to be automated where possible. New device classes, MIB folders and any other avoidable manual steps need to be removed and provided by the ZenPack.
• There are no Priority 1 or 2 defects open for the ZenPack on http://zenpacks.zenoss.org.
• The ZenPack needs to maintain a rating above 80% for the current stable release, with at least 10 respondents reviewing the ZenPack. A new ratings widget will be added to the Community website to enable tracking ratings over time and the version of Zenoss with which it has been tested.

Production-Ready

The Production-Ready classification implies that a ZenPack has reached a level of community testing and quality review that it may be considered ready for production environments.

Production-Ready ZenPacks are supported for Zenoss Enterprise customers.

We anticipate that in a future release Production-Ready ZenPacks will be presented and installable directly from the Zenoss application, without having to go to the Zenoss Community website to download them.

These are the requirements for maintaining the Production-Ready classification:

• With each major release of Zenoss or with major upgrades, the ZenPack will be reclassified to the Community category, until it has been sufficiently reviewed again.
• In response to reviews, a ZenPack may be withdrawn from Production-Ready at any time.
• Production-Ready ZenPacks may be reviewed by Zenoss developers for eventual inclusion within Zenoss Core.
• Zenoss Development may promote individual ZenPacks to Production-Ready by testing the ZenPacks.

ZenPack Types

While ZenPacks provide a wide variety of functionality, they typically fit within the following four categories: Monitoring, Presentation, Functionality and Integration.

Common Documentation Requirements

There are several common documentation requirements for all ZenPacks:

1. Accurate, concise descriptions of what features are provided and the value they provide
2. Supported versions of Zenoss
3. External installation dependencies required (libraries, tools, etc.)
4. ZenPack dependencies
5. Configuration requirements within Zenoss before or after installation

Monitoring

Monitoring ZenPacks add support for monitoring new devices or services to the Zenoss installation. They may leverage existing protocols like SNMP or JMX or use a Command data source to make local or remote shell calls. Typically they provide a device class and templates for monitoring, with the associated thresholds and performance graphs. Some may supply custom modeling and UI enhancements to support their additional functionality. Event mappings and MIBs are included in Monitoring ZenPacks. Documentation requirements for Monitoring ZenPacks include:

1. What device model(s) or services do they target?
2. What device model(s) or services were they tested with?
3. Which protocol(s) do they use to perform this monitoring?
4. Are there any new device classes provided?
5. Are there any collector plugins to be applied?
6. Are there any new or existing properties that need configured?
7. What data points do they collect and have they been aliased (if applicable)?
8. What thresholds (if any) are applied?
9. What is graphed?
10. Are templates automatically bound to the device class?
11. Are there any event mappings?
12. Which MIBs are provided for OID translations?
13. Do they provide any other additional monitoring information?

Presentation

Presentation ZenPacks provide new UI elements, whether through dashboard portlets, new reports or other modifications to the Zenoss user interface. Required documentation for Presentation ZenPacks includes:

1. Screenshots of the new feature.
2. Are there any new or existing properties to be configured?
3. What are the configuration options for this feature?

Functionality

Functionality ZenPacks provide new features within Zenoss. Examples include new data sources, threshold types, monitoring daemons and other enhancements to the Zenoss platform. Documentation requirements include:

1. Screenshots of the new feature (if applicable).
2. Are there any new or existing properties to be configured?
3. What are the configuration options for this feature?
4. What use cases does this feature support?

Integration

Integration ZenPacks provide interoperability between Zenoss and other platforms or tools. Examples include ticketing systems, provisioning tools and other network tools. Required documentation for Integration ZenPacks includes:

1. What platforms, tools or services are being integrated?
2. What use cases does this feature support?
3. How are they being integrated (protocols, tools, etc.)?
4. What versions were they tested with?
5. Is there new monitoring, presentation or functionality provided? If so those additional documentation questions from those categories need to be answered.
6. What are the configuration options for this integration?

Conclusion

Today there are hundreds of ZenPacks at various stages of development, documentation, review and certification within the Zenoss ecosystem. Zenoss Development will continue integrating and documenting Core and Enterprise ZenPacks with these documentation requirements, provide a rating tool for the community ZenPack site and eventually provide automated installment of Production-Ready ZenPacks directly in the application. By providing ZenPack developers the necessary steps to transition their ZenPacks from Experimental to Production-Ready, all Zenoss users will benefit from the ZenPack authors’ efforts.