Servprise Dev Weblog :

WebReboot Nagios Plugin 1.1 Release

Tue, 29 Jan 2008 17:59:00 -0500

I’m pleased to announce the availability of the 1.1 release of the WebReboot Nagios Plugin. This release focuses primarily on usability, although there were several bug fixes and documentation enhancements.

Improvements were made throughout the installation process: progress messages are printed on the console, old settings files are preserved upon upgrading, and a bug with the command definition files not being upgraded was fixed.

The plugins are also now more resistant against WebReboot failures. If a WebReboot goes offline, an error message is logged, but the plugins proceed to work with all other WebReboots in the network. This contrasts with the old behavior, where the plugins would simply error out.

Based on customer feedback, we’ve also added the ability to log to a syslog server, rather than local file. Now you can send your logging information to the same destination that you send WebReboot Enterprise and Nagios messages.

For more general and download information, please check out the changelog. For a brief overview of what the plugins can do or to see them in action, please watch our new overview screencast.

In the same spirit of the 1.0 release of the plugins, we’ve decided to re-run our last promotion. These discounts are made available as coupon codes that you can enter when checking out from our online store. They expire on Feb. 29, 2008:

NAGIOS_FREE_PCM—Free WebReboot Power Cycle Module with the purchase of a WebReboot Enterprise ($125.00 USD value)
NAGIOS_WR3_5PCT—5% off your purchase of a WebReboot 3.0 (approximately $25.00 USD value)

As always, many thanks to those that provided bug reports and suggested new features. These largely drive the development of the plugin suite.

WebReboot Nagios 1.0 Released

Mon, 03 Dec 2007 09:55:28 -0500

I'm extremely pleased to announce the availability of the 1.0 release of the WebReboot Nagios Plugin. After months of testing we feel confident in giving this the 1.0 stamp. This new version now supports multiple WebReboots, allowing you to use a single installation for your entire network. The changes made to support this also cascade down to a single WebReboot installation by way of simpler configuration and better caching, reducing network traffic and increasing command throughput.

For more general and download information, please check out the changelog.

We have now made the plugin part of our official offering and is featured directly on our main site, making it available to a wider audience.

Finally, as part of the announcement we are running a bit of a promotion (some of you may have seen it on the Nagios Web site already). These discounts are made available as coupon codes that you can enter when checking out from our online store:

NAGIOS_FREE_PCM -- Free WebReboot Power Cycle Module with the purchase of a WebReboot Enterprise ($125.00 USD value)
NAGIOS_WR3_5PCT -- 5% off your purchase of a WebReboot 3.0

Once again, thank you to everyone that's been involved in helping get this 1.0 release out the door.

WebReboot Nagios Plugin 0.4 Released

Mon, 08 Oct 2007 12:24:00 -0400

I'm pleased to announce the availability of the 0.4 release of the WebReboot Nagios Plugin. This release is recommended for all users as it significantly reduces the amount of network traffic required to perform a command. More work was done to simplify configuration and gracefully handle error conditions as well.

This is also the first release to feature support for the WebReboot 3.0. Configuration for the WebReboot 3.0 is identical to the WebReboot Enterprise, allowing a complete swap-out with little to no reconfiguration.

For more general and download information, please check out the changelog.

maven-jython-plugin 0.2 Released

Tue, 11 Sep 2007 13:50:00 -0400

I am pleased to announce the 0.2 release of the maven-jython-plugin. Not much has changed since the 0.1 release, but 0.2 is being released because it targets the latest version of Jython (2.2) and Maven (2.0.7). For more information about this release, please see the changelog.

Looking forward, we do have some interesting work on the horizon. Jython 2.3 will remove jythonc, which is the core of both this plugin and the ant one. I had investigate some alternative options in compileall.py, but found it didn't quite meet the goals of this plugin. Once that is reconciled, quicker and more featureful releases should be produced.

Broken Comments

Tue, 11 Sep 2007 09:54:00 -0400

We recently upgraded our weblog engine from Typo 4.1 to Typo 4.1.1. In the process, the Jabber configuration got messed up and the net effect was that no comments could be submitted.

At this point, we think the problem has been fixed and apologize for any inconvenience. If you wanted to comment on any posts, please feel free to do so now.

URLConf: Time for an Overhaul?

Mon, 10 Sep 2007 09:25:00 -0400

Recently, there was a discussion on the mailing list relating to a potential overhaul of URLConf. I really didn't get involved due to time constraints, but I did think about the matter. URLConf is one the core features of Django and has remained largely unchanged in the two years since I started using the framework. Two of the core tenets of modern Web application frameworks are Don't Repeat Yourself (DRY) and convention over configuration; traditionally, URLConf has broken both.

On the DRY front, URLConf has come some ways. Django 0.96, the latest released version, added the url template tag, which made it possible to generate URLs in your templates without needing to repeat the same info as in your URLConf. There was a limitation relating to view reuse, but the SVN trunk version of Django fixes this problem. Hopefully a 0.97 release is not terribly far off, making the enhancement available to a wider audience.

The issue of convention over configuration, however, has largely been unaddressed with regards to URLConf. If you want to serve up a page, you add a URLConf entry -- that is the Django way. Sure, other things can be done, but you have to go out of your way to do it. We came across this limitation hard when converting dev.servprise.com, which was largely a static site, over to Django. Having to specify a new URLConf entry for each ported resource was cumbersome, so we resorted to custom middleware. I posted the snippet so it could be used by others, and in the process learned of other solutions via comments left about the snippet. While educational, I was left wondering why this burden is placed on each individual developer. This seems like a large step back from using a Web application framework at all. In the old days, I put a file in a directory and Apache served it up. It was the ultimate in convention over configuration. If the Apache folks told me I needed to add a Location tag for every URL I wanted to serve, I'd have thought they were insane.

Moreover, having one entry for each served up resource means that the URLConf can quickly grow out of hand. Once again, being that it is all Python code, there are surely ways for each developer to handle the complexity, but these approaches address the symptoms, not the problem (thanks Malcolm). One of the proposed solutions to the problem pitched in the aforementioned discussion is using a decorator on the view function to dynamically add URLConfs. This, to me, wasn't actually all that bad of an idea. I'd propose taking it a step further though.

If URLConf entries are simply mappings from URLs to views, and each element in that mapping is adequately named, why not let the view name dictate the URL? This also would advocate a cleaner organization of views (rather than a monolithic views.py), using the package name to build up URLs. As an added benefit, it is consistent with the approach taken by the url template tag. Undoubtedly, this has flaws as well. Mapping the same view to multiple URLs is going to require some additional thought. This is the same problem I mentioned with the url template tag in Django 0.96. My gut feeling is that code delegation in the view functions is an adequate solution. In those cases where it is not, use URLConf as the fallback. There is no need to remove URLConf altogether, but it should be the fallback rather than the primary way to map URLs to views.

To address issues of "magic" in the URL mappings, I'd either enhance the sitemaps contrib app or create a new one that could graphically depict the page's organization via URL templates to particular views. This sort of app could be useful right now, actually. Magic or not, getting a good handle on a site's structure can be a daunting task.

Questioning how URLConf could be better is one of the first steps in progress. I proposed a potential solution, but invariably, it has its own set of flaws. I'd like to see a good discussion on the matter, perhaps during the upcoming sprint, and see a better solution prevail.

WebReboot Nagios Plugin 0.3 Released

Wed, 05 Sep 2007 08:10:18 -0400

I'm pleased to announce the availability of the 0.3 release of the WebReboot Nagios Plugin. This release continues the configuration simplification process started in the 0.2 release. The error logging and reporting aspects of the plugin have seen a lot of care in this release, making it simpler for a user to fix or properly diagnose any problems with the plugin configuration. Additionally, a bug related to the temperature monitoring feature was fixed. This is a recommended upgrade for all plugin users.

For more information and download information, please check out the changelog.

Satchmo and newforms-admin

Wed, 29 Aug 2007 11:28:26 -0400

We started evaluating Satchmo for our main store page when we discovered that Satchmo 0.5 does not support the newforms-admin branch of django. Satchmo tracks the latest django trunk, which does get merged back into newforms-admin periodically. Unfortunately, Satchmo appears to augment or at least rely on the old-style admin site. As such, it will not run using the newforms-admin branch. This is a bit of an issue for us, since we have come to rely on having newforms-admin.

We'll probably set up a separate environment to test in, but even then, Satchmo may be problematic for us. It's one thing for us to have to chase trunk or newforms-admin revisions and a completely separate one to coordinate with a third party project that also relies on an unreleased/unstable version of django. We have run into issues in the past with different developers in our own team running "svn up" at different times and running into inexplicable issues with the code, only to find out it was related to update timing. It's something we do not look forward to doing with another remote team.

The project does look interesting though and we'll likely weigh in on it more as we further evaluate it.

Django newforms-admin AlreadyRegistered gotcha

Wed, 22 Aug 2007 19:53:16 -0400

While converting one of our internal django-based applications to the newforms-admin branch, we were snagged by a little gotcha. After following the migration docs, we fired up our app and immediately upon accessing it, were presented with AlreadyRegistered exceptions. These exceptions are thrown if you attempt to register the same model twice with the same admin site instance. We found this odd, given that we were quite sure that we only registered the code once, in exactly one place.

The culprit turned out to be our use of "from models import *" in our URLConf. The newforms-admin docs currently have all of the admin registration at the bottom of the models file. The idea of putting them there is to guarantee that the code gets executed at some point. The problem is guaranteeing that it gets executed exactly once. By django loading up the models file, the registration was executed once. By us calling the star import in our URLConf, the registration code was being called again, causing the exception.

In the aforementioned docs, the authors mention having a preferred location for the admin site configuration. We ended up heeding it and created an admin.py file to contain everything. This file is now star imported from our URLConf to ensure the registration does proceed. However, by splitting them, we prevented multiple registration and better decoupled the admin site configuration from our models.

Anyway, this is a little gotcha if you're moving to newforms-admin, which will likely be a requirement for the 1.0 release of django.

WebReboot Nagios Plugin 0.2 Released

Fri, 17 Aug 2007 17:58:00 -0400

I'm pleased to announce the availability of the 0.2 release of the WebReboot Nagios Plugin. This release features massively improved configuration, logging, and documentation. If you're using the 0.1 release, we highly recommend you upgrade.

For more information, please check out the changelog, where you can also download the release.