Zenoss Blog: No Node Left Behind

Hunt Bugs And Travel

community@zenoss.org — Wed, 08 Feb 2012 15:49:41 GMT

Now that the first Core 4 alpha artifacts are out, we're excited to hear everyone's feedback. Specifically, I am challenging you guys to bury the developers in bugs. As all of you know, this is the first major Core release in more than 12 months, so we really need everyone's help to hammer out the new release. We all want this to become the best and most stable release of Core ever, that's why we're having a bug hunt.

As prizes we're giving away the most exciting stuff we've ever had. We're flying the top three participants to Austin, for an all expense paid "Zenoss Mastery Class". This will be an exclusive opportunity to receive training from the best (Chet, Eric, Ian, etc.), an offer that has never been available to anyone before.

In order to make this hunt effective, fair and possible, we've come up with the following processes/guidelines/rules (legal fineprint):

All participants that submit at least one valid/confirmed bug will receive a limited edition T-shirt.
All participants that submit anything (even if unconfirmed) will receive a limited edition sticker.
We will make new builds available on a daily basis. As developers work on fixing bugs, you guys will always have access to the latest ready-to-install artifacts, so you can be assured that a bug you're finding is unfixed (as long as you're using a fairly recent build). This means the artifacts will not be available from the usual download site, but from Sourceforge instead.
In order to receive points, a participant has to create bugs using http://dev.zenoss.org/trac/newticket (user: zenoss, password: zenoss). The created bugs should follow these guidelines (see example screenshot below):
- Bugs shall be classified as Priority 1, 2 or 3 (detials see below)
- Bugs shall carry "[bughunt]" in the title
- Bugs shall have the reporters email address as the Cc
- Bugs shall use the default ticketing template (build number, reproduction steps, etc.) wherever possible
During the twice weekly defect review meeting, a team of people from development and support (including myself) will review all submitted bugs. During this review process, we will check for duplicates, make sure the guidelines in 2 have been followed and the bug isn't a duplicate. If all checks out, we will assign points accordingly.
The Bug Hunt will end upon the relase of the first release candiadate (RC) of Core 4, which is planned for mid-March.
In order to qualify for one of the main prizes (the Zenoss Mastery Class) a participant must at least have 16 points.

Priorities and Bug Hunt Points

Priority	Bug Hunt Points	Description
1	8	System crash, loss of data, loss of monitoring. This bug will take top priority with development and stop the release of the software until fixed.
2	4	A Feature is not functioning and no workaround exists. Next highest priority for development; will not hold up release.
3	2	A Feature is not functioning a workaround exists.
4	1	Lowest severity, minor issues, cosmetic issues.

Example Ticket

Image Credit: Gunther Swanh

The pain with Crowbar testing!

community@zenoss.org — Thu, 02 Feb 2012 16:06:48 GMT

Originally Posted on Google+ http://bit.ly/z99Wra

The last few weeks I’ve been working with Dell’s OpenSource project named Crowbar. This software provides the ability to manage and automate large data center deployments from the bare metal. The software is extensible by deploying software packages called barclamps and Keith Hudgins at DTO has developed an open source Zenoss barclamp. So my task was to test the installation of this barclamp and provide any help that I can.

Prior to starting on the project of testing the Zenoss barclamp I had heard of the Crowbar project while attending the local OpenStack meetups. Dell is a major player in the OpenStack community and their Principal Crowbar Architect Rob Hirschfeld has led this group from the start. So it goes without saying that Dell provides information on this project during the meeting.

The Crowbar installation consists two major software packages, Crowbar Admin server and Opscode Chef server. When installing I had the option to download the repository from GitHub and build my own ISO file or simply download the ISO from crowbar.zehicle.com. This ISO was built by Rob and is provided with no support from Dell. The ISO version I chose to install was Crowbar 1.2 Final which is just over a month old (as of Jan 31 2012). I’m currently working on building the ISO to further our testing environment.

Since the Crowbar software has some special network requirements I decided not to deploy to our internal OpenStack cloud. As I get more experience with the software it will be moved to our OpenStack environment if possible. The actual installation from the ISO was very straight forward and I was able to deploy to my local installation of VirtualBox. The first step was to create a virtual machine and boot to the ISO image. Once at the command line I made a simple modification to the JSON file for networking and I was up and running in about 20 minutes.

The Crowbar admin server provides the following network services PXE, DHCP and DNS after installation. Once a new bare metal machine is powered on it should send out a PXE request onto the network. At this point the Crowbar admin server provides a very small CentOS 5.7 image to get the basic services installed. The system will show in the Crowbar admin interface as a blinking “UnAllocated” system. It will stay in this state until the administrator assigns the node to a “Proposal”. A proposal is the additional configurations the user can place on a barclamp. All barclamps must have at least one proposal assigned to them. This is also the location to assign any nodes to their role. Once the proposal is applied or once the node is allocated Crowbar admin server triggers the OS installation (based off of the assigned os proposal) and Chef Client installs. Several reboots will happen, during which time the assigned proposals (which map to chef roles) will be applied.

To add additional proposals to a node I simply have to edit the proposal and add the node. The apply button on this screen will trigger the immediate installation of the proposal and the save button will only save the changes to the proposal in case I want to deploy at a later time.

The next step was to deploy a client machine that Crowbar could provision as a Zenoss server. As I did for the Crowbar server I built a new virtual machine in VirtualBox but this time I had to prepare it to perform a PXE boot. After several failures to boot to PXE I realized that the VirtualBox setup may not have been the best way to first test Crowbar. I wasn’t sure if Crowbar had a problem or if my VirtualBox had a problem. In the end it was mostly the VirtualBox settings and resource restrictions.

The problems in order and how I resolved them.

After the initial startup of the virtual machine it would not attempt to a PXE boot. Only the local hard drive was checked for an OS. What I found was that the default network adapter (Intel PRO / 1000) did not support PXE boot. Some trial and error and I found that the PCnet-FAST III adapter was the one I needed. Not sure if it was necessary but I also set the “Promiscuous Mode” to “Allow All”. I also had to make sure the “Network” was selected to be included in the “Boot Order” under the “System” configuration tab.

Now the vm was able to PXE boot but could not locate the PXE os image. After taking a network captures with tcpdump I found that another DHCP server was answering the PXE call from my client. By default VirtualBox networks have DHCP server enabled. Even after disabling the DHCP server and restarting VirtualBox the rouge DHCP server was still answering the call. I removed the network configuration and recreated a new Crowbar network with no DHCP server. This did the trick and I was up and running my new client.

The next step was install the Zenoss barclamp into the Crowbar server. This is done via a command line interface and is very basic with very limited options. One option that was very helpful was the --force option which forcefully overwrites the previous barclamp installation.

At this point I started to encounter problems in the UI for Crowbar that I’m not sure if they were caused by the installation of the Zenoss barclamp or if the software itself was at fault. This brings me to my big issue with Crowbar. Trying to figure out what is going on with the Crowbar server is a challenge at best and impossible most of the time. The UI only provides blinking status lights and when an error happens the message provided is useless. You are left to log in and dive into the local log files. The unfortunate problem is that the log files have been placed in several different locations, none of which I found in documentation on any of the sites Dell recommends. The IRC chat was the only helpful location I was able to receive answer from on how to troubleshoot. Since this is an open source project it will be up to me to update the GitHub wiki with this documentation

After I moved on from my UI challenges with no real resolve I received errors that “Failed to apply the proposal”. Once again I looked into the log files and found nothing. Since Crowbar is tightly coupled with Opscode Chef and I wasn’t seeing any errors that could help I turned to applying the cookbook directly from the client. This resulted in my finding that the Zenoss cookbook was failing since it had external dependencies for the software installation and the vm network did not have an external network link. I quickly resolved this by commenting out these files in the cookbook as they were not required for that particular build. The installation then completed and the Crowbar server now showed the successful installation of the Zenoss server.

The next step was to deploy a Zenoss client but since my VirtualBox was limited on resources I had to move to another testing environment. Without going into great detail the new environment was a KVM hypervisor running on Ubuntu with 8GB memory. This environment did have a network connection to the outside network so all Chef cookbooks downloaded external dependencies with no problem.

The Zenoss client installed with no problems and automagicly added itself to the Zenoss server installation. A closer look a the Zenoss client cookbook showed that it too has an external network dependency. We have forked the Zenoss barclamp and are working on getting these updates and some others pushed back into Keith’s repository. He has been assisting us during this testing phase and is looking forward to the updates.

In the end I have to say Dell has a great project here with Crowbar. It was very simple to setup and is very powerful when all is working. But I have to say when it fails, telling me that the proposal has failed to install isn’t very helpful at all, more details please or even a help file link to provide me with location of resources to use. Most of the challenges I faced during this test was either with the cookbook recipe or the VirtualBox configuration and limitations. Understanding that Crowbar is a very new project I’m impressed with how far they have come. It will only get better with community involvement so step up and dig deep and we all will win!

Farewell Zenoss Community

community@zenoss.org — Wed, 01 Feb 2012 16:05:10 GMT

Zenoss Community Members,

I am moving on from my role at Zenoss Inc. in the open source community. I am looking to venture into new areas and opportunities. I have had a great 3 years at Zenoss: learned so much, worked with brilliant minds, experienced open source kindness, enabled cooperation, and helped to build a systems monitoring / assurance platform that is at the top of the list.

I hope to continue occasional interactions with the Zenoss open source community as a tried and true open source user / member. Look for me in IRC, or feel free to contact me personally: nyea...@ umbc.edu

Thanks for the great memories and experiences!
-Nick Yeates

Core 4 Alpha is Now Available!

community@zenoss.org — Tue, 31 Jan 2012 20:00:21 GMT

We are happy to announce the Zenoss Core 4 Alpha release to the world! This is the biggest Core release in the history of Zenoss and we are really excited about all of the new features included in this major release.

We know it's been a long time coming and we think the wait was worth it.

As part of this announcement, we will be holding a bug hunt competition. More details on the bug hunt will be forthcoming over the next few days.

Since this is an alpha release, we do not officially support product upgrades from Zenoss 3.2 to the Zenoss Core 4 alpha release or from the alpha release to future product versions. However, we would appreciate validation and testing of upgrades as part of the bug hunt competition.

An excellent technical primer on the new features and architectural changes can be found here

Zenoss Core 4 Major Features

New messaging framework (RabbitMQ) to allow for horizontal scaling of event processing
Real time notification and command executiion via triggers
Extended JSON API support
AMQP support for enhanced product integration at the messaging layer
RelStorage, which replaces ZEO and improves the performance of Zope object database queries
Scalability improvements to zenperfsnmp
UI refresh and Ext JS 4 upgrade
Significant improvements to the event processing system, increasing to 100M+ events per day
REST API for querying events
Support for SNMPv3 traps
Ability to monitor devices directly over IPv6
Performance collecting daemons have moved to the collector framework for more consistent operation and higher reliability
Enhanced event suppression with zenping

Any suggestions/feedback on the Core 4 release are welcome and can be submitted here

Installation and Release Notes

Installation and upgrades details are covered in the Zenoss Installation Guide and Release Notes for Zenoss Core 4

Core 4 Alpha Download

The State of Open Source Survey (and self-introduction)

community@zenoss.org — Wed, 25 Jan 2012 18:30:14 GMT

Hi everyone!

You're probably wondering who I am and why I'm posting something here. In short, I joined Zenoss last year to work on social media strategy. I've been very much behind the scenes on the social front but finally have some bandwidth to put forth a dedicated effort.

Anyway, I'm very green in both the IT and open source worlds but don't have a problem admitting it. I'm here to learn, contribute in a meaningful way whenever possible, and work to make Zenoss an even bigger force to be reckoned with.

So in my first post, I'm actually picking up the lead on an open source we've done for the past 4 years. We worked to get this survey ready for LISA last month and if you attended, you probably found our booth and perhaps filled out this survey for some boxers. Last week, we also sent this out in an email, with some great responses too.

To make sure this survey gets the full impact it deserves, we'd really appreciate it if you had a few minutes to answer these 13 questions. The survey can be found here:

https://www.surveymonkey.com/s/H7K9PJV

Once we close the survey and get the results, we'll send it your way if you've filled out your name & email (optional). If you do fill this out, we'll be doing a drawing for a Sonos Play Wireless Speaker. (side note: I've already received feedback that this giveaway could be better, so please, leave your suggestions)

If you want to check out results from the previous survey, Mark did a post on it here: http://community.zenoss.org/blogs/zenossblog/2010/08/10/2010-trends-in-open-source-systems-management

Thanks!

OpenVZ and Zenoss

community@zenoss.org — Tue, 24 Jan 2012 19:24:19 GMT

Hi everyone!

It's great to now be a part of the Zenoss team, where I am assisting Zenoss Labs in their efforts advance the capabilities of the Zenoss platform by developing new ZenPacks.

For my initial ZenPack, Chet offered a couple of options, and "OpenVZ" was one of them, and I made a pretty strong request to be able to tackle the OpenVZ ZenPack first, as I'm a big fan of the technology.

I have been using OpenVZ for quite a while and the Linux distribution I now lead, Funtoo Linux, has good support for OpenVZ. So I was excited to be able to add some really advanced OpenVZ support to Zenoss. I am pleased to announce that the OpenVZ ZenPack is now available to the public. It is compatible with Zenoss Core 3.2 and the upcoming Zenoss Core 4 release. It is available on GitHub at the following location:

https://github.com/zenoss/ZenPacks.zenoss.OpenVZ

Detailed documentation has been provided in README.rst which you can browse by scrolling down on the link above. (ZenPack Developer note: we are moving to ReStructuredText as standard for ZenPack documentation -- more info in a future blog post)

I should probably introduce OpenVZ to those who may not be familiar with it, and then give you some insights into the full monitoring capabilities that have been integrated into this ZenPack.

What is OpenVZ?

OpenVZ (see http://wiki.openvz.org) is an OS-level server virtualization solution, built on Linux. OpenVZ allows the creation of isolated, secure virtual Linux containers (called "VE"s) on a single physical server. Each container has its own local uptime, power state, network interfaces, resource limits and isolated portion of the host's filesystem. OpenVZ is often described as "chroot on steroids."

It is a very capable and mature platform for creating high-performance Linux-based clouds, and is used quite extensively by hosting providers and commercial organizations. The project is supported by Parallels and it has a commercial version called Virtuozzo.

The appeal of this technology is that it can fully isolate Linux-based images from one another without incurring any significant "virtualization overhead", that slight (sometimes significant) performance degradation that we typically accept as the cost of going virtual with a more traditional hypervisor/paravirtualization-based virtualization solution.

It does this by utilizing a single Linux kernel for all containers on the OpenVZ host device. An OpenVZ RHEL5 or RHEL6-based kernel has been enhanced so that it can manage each container's memory, processor and networking resources independently and provide isolation between each container, while offering bare metal performance.

The OpenVZ ZenPack

Now, let's explore how this ZenPack extends Zenoss' existing monitoring capabilities.

While Zenoss always has had the ability to monitor an OpenVZ host system and containers as standalone devices by connecting to the host and containers directly using SSH or SNMP, it did not have the ability to understand the relationship between the OpenVZ host and the container. It also did not have the ability to "see" containers by simply monitoring the host.

This ZenPack allows you to see the containers as components within an OpenVZ host even if you are not actively monitoring the individual containers. A number of metrics are made available for the containers without requiring monitoring to be configured on the containers themselves. This is a great benefit for hosting providers as well as large enterprise OpenVZ deployments.

With this ZenPack, it is also still possible to monitor containers "the old-fashioned way", as Linux devices by using SSH or SNMP, and if you do this, Zenoss will now be able to "connect" the OpenVZ host to the container device that you are monitoring. For containers containing production workloads, this dual-monitoring approach allows you to use traditional Zenoss monitoring and alerting functions within the container. It allows you to monitor both OpenVZ-specific metrics as well as traditional Linux metrics.

Advanced Features

I have also made this ZenPack very powerful in regards to what metrics it can monitor. Anything exported by /proc/user_beancounters or /proc/vz/veinfo can be monitored, and I try to provide normalized "byte"-equivalent metrics for everything I can. Several example graphs are included, and appear as a graph for each component. Here are some samples:

In addition, I have implemented a special graph called "OpenVZ Container Memory Utilization" that calculates the percentage of memory used for all containers on your OpenVZ host using formulas supplied by the OpenVZ developers. This graph can be used for capacity management purposes, to see how much additional untapped capacity is left in your OpenVZ deployment, and how "close to the edge" you are when it comes to memory usage:

Enjoy the OpenVZ ZenPack and let me know how it works for you!

HardCore 4

community@zenoss.org — Mon, 19 Dec 2011 22:22:08 GMT

Our BoF session at LISA was probably a real treat to anyone familiar with Core 3.x. It actually provided a first technical preview to some of the major things coming to Core 4. Due to scheduling conflicts at the show, attendance wasn't too impressive, but most everyone seemed very interested in what I had to say. Retrospectively, I thought to myself that the content would actually be quite valuable for users as well as customers well outside of the select crowd at LISA. While we at Zenoss obviously claim an x-times speed improvement, no one really has done a compare-and-contrast between Zenoss 3.x and 4.x -- and definitely not from a technical perspective.

Thanks to Travis' foresight and hard work we now have an awesome video of the whole session, and I hope you get something out of it. Keep in mind that this isn't called "A Gentle Introduction to Core 4", instead I wanted to focus on an audience that is somewhat familiar with Zenoss 3.x. Hope you guys get something out of it, comments and questions are welcome. Video below, slides are available from: http://www.slideshare.net/simonjj/an-introduction-to-core-4

Monitoring URLs as Device Components

community@zenoss.org — Wed, 14 Dec 2011 20:48:26 GMT

The check_http plugin is a robust tool for doing basic HTTP checks, and has many useful capabilities.

Most Zenoss users probably get to the point, however, where would like to check multiple URLs on the same device. With the Device-based template that ships with Zenoss, this makes handling the templates somewhat awkward. I have tried to solve this in several ways, each has had its drawbacks.

With great thanks to the community, particularly the “Example Zenpack” and the “MenuExamples Zenpack” (this wouldn’t have been possible without them), I have achieved a decent solution that fits well within the standard “Zenoss” management framework.

I’ve published a Zenpack that provides a “wrapper” around the basic “check_http” plugin that ships with Zenoss and with Nagios.

The key is to treat each HTTP monitor instance as a manually-added device component (like a File System). The component is not affected by the modeler process, but individual URLs can be added/removed/modified through the device “Add Component” menu (thanks again to MenuExamples).

The particular attributes for each URL are assigned through a dialog:

But can be later modified on the component Details pane:

Since it’s a component, the RRD template is applied separately to each monitored URL, which each set of graphs displayed uniquely per URL (like other device components).

Additionally, there’s a “wrapper” shell script included with the Zenpack that handles the optional arguments before passing them to the check_http plugin, so it can handle the component attributes that may or not be present (such as authentication, found string,POSTs,etc).

While it may need a bit more polish (for instance, a complicated URL could contain invalid characters for the component ID, and I haven’t fixed this yet), I think this is a good way to handle the need for multiple manually-created monitors on a single device, and I plan to re-use this model as a “skeleton” to

handle other similar monitoring needs (like generic NRPE checks and log file monitoring).

The Zenpack is here:

http://community.zenoss.org/docs/DOC-12940

-Joseph Anderson

LISA is the place to be for IT Ops!

community@zenoss.org — Fri, 09 Dec 2011 19:47:59 GMT

^ KeyNote Speech Youtube Vid ^

The Zenoss community team, an engineer, and our social marketing guru have been live at the LISA conference (Large Installation System Administrators) for the past week and we have had some great interactions and learning expereinces.

Roaming the halls are the founders of popular open source tools like RRDTool, and Nagios. Industry heavy weights are teaching classes and holding interactive small scale discussion questions. Google, dropbox, and more are looking for top hiring talent. The environment is super-light weight, casual dress and casual behavior is encouraged, and self-spun groups stay up till 3am talking shop or playing card games.

Example interactions

I attended one technical session explaining how 2 TBs of 9/11 images and video were distributed freely to the public at NIST. The team was from a sys admin background, but were doing this as their first development project. They said that this was their first venture into the famed DevOps principles. I attended another session on ITIL usage and there was lengthy discussion on ITIL vs DevOps and continuous improvement. How can you be locked down by books and books of standards and advised ways of doing things, while also taking the benefits of agile methods that DevOps entertains. Other talks were heavy with cloud implementations and integrations, also there were many companies looking to integrate configuration management with various methodologies and systems.

IRC live on floor

Our IRC community chat channel (#zenoss) was live on the floor at the Zenoss booth. Matt Ray unexpectently announced that the OpsCodes Chef product (who was also in attendance at the show) now has integration with the latest version of Zenoss (3.2.1). I wrote this on a sign and got many interested reads, as there were dozens of attendees interesting in mixing their Configuration Management solution with a monitoring and assurance solution (Chef -> Zenoss, Puppet -> Zenoss, etc). This goes to show the technical aptitude and quality of the people making up this conference. Top-notch.

Core 4.0 Architecture reveal - Video coming

Simon given a superb overview talk on the new architecture that is coming to Zenoss Core in the form of our Avalon codebase in version 4.2 (or it might be 4.1.1, this is up in the air). We will post a video of this architecture talk and will summize features and inclusions that will come with the new exciting version!

What we're working on

Continued work goes into ZenPack documentation by Chet, and I continue to pound out automation of the Community ZenPack submission framework.

Please do comment or leave us questions.

Developers: Sync your existing ZenPack with Github

community@zenoss.org — Wed, 23 Nov 2011 22:24:48 GMT

As we have announced, we have moved all of the Community ZenPack code and process to Github.com . This means that existing ZenPack developers have code that they may have updated, yet is not reflecting on github. Below explains how you can get your existing ZenPack code sync'ed up with github.com repositories.

Master repos at github.com/<user_name>

Please note that we are making a move to keep all new ZenPack code within the authors github space - ex: https://github.com/dpetzel/ZenPacks.community.Varnish3 . This URL is the master repository for this ZenPack. We are no longer keeping new ZenPack code at https://github.com/zenoss . There will exist old ZenPacks under github.com/zenoss as we phase these out over time. Follow the below instructions and we will step in if something is wrong.

Instructions

All steps below are detailed here: ZenPack Development Process and summarized In Quick Commands

Assure that github account is attained, git is installed and setup
Create a separate directory for your ZenPacks
- mkdir /gitrepos
- It is good practice to assure that your developed ZenPacks are separate from $ZENHOME/ZenPacks
- You will reinstall the ZenPacks in this new dir later with the --link command option, so that the ZenPack installs in place
Follow #1A Fork and Clone
1. In web-GUI: fork https://github.com/zenoss/ZenPacks.community.FormulaDataSource to https://github.com/rmatte
2. git clone git@github.com:rmatte/ZenPacks.community.FormulaDataSource
Get into the newly cloned directory ( Ex: cd /gitrepos/ZenPacks.community.myZenPack )
Bring new content into this repository
- method A: manually bring over the files that you know you updated; good if its just a few files; advised if possible
- method B: rsync -av old new && git diff
  - Note: a conflict could occur, and code lost, if another person has worked on your zenpack in your absence. Be smart.
Insert needed files
1. .gitignore file into root repo directory (IMPORTANT)
  - wget https://raw.github.com/zenoss/Community-ZenPacks-SubModules/master/.gitignore
2. README.rst
  - The new replacement for ZenPack documentation; At the least, type a sentance
  - vi README.rst
zenpack --link --install <zenpack_name>
Follow steps #3 Commit locally and #6 Push to personal github
Fill out the google docs Submission Form to let us know

New ZenPack Landscape!

community@zenoss.org — Thu, 03 Nov 2011 05:00:32 GMT

We would like to announce a wave of changes that are aimed at substantially improving the open source ZenPack atmosphere. We need YOUR help to make it successful by embracing the new ways and using git / github!

If you take away one thing

Completely new process to sharing ZenPack code (See second bullet below)

Whats New?

Github repo seperation We have moved to many seperate repos held at github.com/zenoss <-- click to see them Used to be one large repository named 'Community-ZenPacks' Only accepting new code into Many Repos method See new instructions below...
Definitive ZenPack process guide How to create, setup, distribute and publish ZenPacks Replaces and integrates the popular PDF guide by phonegi Covers: Prepping a ZenPack, committng your code, pushing to github and best practices (watch screencast)
Google Form to submit ZenPacks No more emails - we aim to automate the process - this will help Feel free to email us when there are complications
Anyone can edit the ZenPack List Wiki-like editing for all Add your ZenPack to the list where everyone goes to get ZenPacks See link above to login and edit!
Backlogged ZenPacks All up on Github.com/zenoss

The Future

(potential directions)

Automation, Automation, Automation
- We want to automate as much of the process around ZenPacks as we can
- This means less human error, immediate gratification, less work and a growing community!

README's == jump page == documentation
- We want the doc and download page to be developed and held IN the ZenPack itself.
- Start putting markdown flavored ASCII documentation into your README, README.markdown, or README.txt's!

Continuous Integration / QA
- We want to build all ZenPacks every night and know which install and which do not
- Quality and compatibility of community ZenPacks will increase

Product Integration
- zenpack --install http://github.com...
- Button in UI to download ZenPacks from the cloud (github.com)
- Button in UI to publish newly developed ZenPacks

Why should I learn Git / Github?

Resume builder
- Git is the future of Open Source software code management
- Add it to your resume & use it at future jobs
Encourages others to Edit
- It eases looking at your code and even changing it
Transparency
- You will be able to see what others are developing in-progress
- More easily get help from others when you are stuck
- Github is a social platform; start working with others
One Place
- Code, versions, .egg downloads, documentation
Instant Gratification
- You will be able to reference your code and .egg as soon as you post to your personal github space
Will excel the Zenoss ZenPack Community

IRC Session Today

community@zenoss.org — Thu, 27 Oct 2011 14:54:50 GMT

Thursday Oct 27th at 11am EDT in the #zenoss IRC channel on irc.freenode.net (port 6667).

Zenoss engineers Simon Jakesch, myself Nick Yeates , and various others will be in attendance to help you out.

Don’t forget you can search for answers to common questions by visiting the Forums.

Additionally, we log all chat traffic and sessions on the IRC Community.

Zenoss Core 3.2.1 is now available!

community@zenoss.org — Sat, 22 Oct 2011 16:08:47 GMT

After much testing and a few beta releases, we are proud to release the latest (and possibly last) version of the 3.x series. The original reason for the 3.2.1 release was the finding of two key bugs by the community. We have squashed the two original bugs, and fixed many others that were found in the process. This is primarily a maintenance release.

Important Upgrade Note:

If you are upgrading your Zenoss installation, it must be at version 3.1.0 or greater. See the release notes for upgrade-path details.
The Upgrade Path is roughly: 2.5.x* -> 3.0.3 -> 3.1.0 AND 3.1.x+ -> 3.2.1
The * is about running the preupgrade ZenPack first (before upgrading from 2.5.x)

Bugs Fixed

The 3.2.1 release of Zenoss Core includes fixes to high-priority defects, including:

External Defect 7859 - RRD files are not updated if OID starts with . (period)
External Defect 7860 - zencommand - data sources not collected
See other public issues that were fixed in 3.2.1
See 115+ other bugs (many enterprise-based) and features list at the bottom of the 3.2.1 Release Notes (pdf)

ZenPack Updates in Core 3.2.0

LDAP Monitor Fixed error when changing bind type in ticket 28807

Developer IRC Session Thursday Sept 29th

community@zenoss.org — Thu, 29 Sep 2011 14:18:50 GMT

Thursday Sept 29th at 11am EDT in the #zenoss IRC channel on irc.freenode.net (port 6667).

Zenoss engineer Joseph Hanson and myself Nick Yeates will be in attendance to help you out.

Last Week, we discussed:

IBM System X monitor,
components in zenpacks,
copy vs override template,
ZenPack-creation document,
ZenPack template by Chet
RRD do not refresh in 3.2

Don’t forget you can search for answers to common questions by visiting the Forums.

Additionally, we log all chat traffic and sessions on the IRC Community.

Release of Beta #2 for 3.2.1 - added stack and vmware installs

community@zenoss.org — Fri, 23 Sep 2011 18:47:31 GMT

Short and sweet, go pick up beta release #2 of 3.2.1 here:

http://alpha.zenoss.com/files/

This time around, there are VMWare images and Stack installs.

All the same info from the prior post, applies here.