To stop further mailing, go here or write:
PinpointMediaServices, 4255 E. Charleston Blvd. Suite D-345, Las Vegas, NV 89104
PinpointMediaServices, 4255 E. Charleston Blvd. Suite D-345, Las Vegas, NV 89104
It's time for This Week in OpenNMS. This week we did more SMS work, and released a new stable version of OpenNMS. Project Updates --------------- - Stable: Current Release is 1.6.5 1.6.6 is the current stable release, tagged September 18th. It fixes a number of bugs, and adds a few features. For a full list, see the bugzilla 1.6.6 milestone. This is a non-critical but recommended upgrade for anyone on OpenNMS versions older than 1.6.6. - Unstable: Current Release is 1.7.6 1.7.6 is the current unstable release, tagged August 3rd. Since 1.7.5, there have been a ton of bugfixes, as well as updates to the RESTful interfaces, inventory report updates, syslogd updates, collection updates, new OpenManage and Cisco IP-SLA monitors, thresholding updates, provisiond updates, map updates, and probably more stuff I'm missing. A 1.7.x overview is available in the release notes on the site. - Unstable: SMS Pinger/Request-Response API We continued work on the SMS monitor, including wrapping up the basic design of the sequence monitor, and are now working our way through bugs and other minor feature additions. - Unstable: DNS Import Handler Dave did some refactoring of the DNS import handler and provisioner to make it easier to get import data from different types of sources. (More on that below.) More on the DNS Provisioning Enhancements ----------------------------------------- Dave sent me a little note describing more about some enhancements he made to the provisioner, and the DNS provisioning process: A new enhancement was made to the Provisioning service of OpenNMS. In pursuit of version 1.8, the merger of Capsd and the Model Importer has resulted a new Provisioning Service daemon in OpenNMS (Provisiond). Based on the Model Importer, XML encoded nodes/interfaces/services can be imported into the OpenNMS DB under the assumption that the source generating the XML would be make this XML available via a URL Resource (i.e. file:// or http://). In 1.6 and in 1.7, most often the source is a "file:" URL and is created with the OpenNMS WebUI. For 1.8, this XML has been given the formal name of "Import Requisition" or simply "Requisition". A new protocol handler was developed last week allowing the specification of a the URL "dns://". This new URL takes the form of "dns://[:port]/" such as "dns: ". A zone transfer must be allowed from the OpenNMS server and the new protocol handler returns a to the Provisioner the XML requisition of nodes/interfaces/services based on each "A" record returned from the Zone. Additionally, the model-importer.properties configuration file where a single URL resource and a single Cron based import schedule could be defined, has been upgraded to an XML based configuration container. The new container allows multiple URLs to be defined each with their own Cron schedule. Getting a Bit More Agile ------------------------ As our team grows here at The OpenNMS Group, we've started needing to manage our time better between paid development, community contributions, and release management. This week we're starting out on a new agile/lean methodology called scrum-ban[1]. It's a combination of agile development and the "kanban[2]" just-in-time methodology for doing engineering production. (If you're in any way interested in development process stuff, I heartily recommend reading that last link, it's neat stuff.) I'm not sure how I feel about the idea that I'm actually excited about introducing more structure into our development process, but I am. My hope is that what you will see come out of this is more regular communication of features as they're implemented, better management of branches and releases, and overall, smoother development. One thing that will change from the point of view of people keeping up with development is that our nightly builds will be based on more up-to-date code. When 1.6 went golden, we implemented a dual-branch strategy. We wanted it to be easy for anyone to make bugfixes to stable, but wanted to make sure we had a peer review process so we're less likely to put out changes that cause issues in the production release. So, we have 2 branches: 1.6, and 1.6-testing. 1.6-testing is open season for anyone with a commit bit, if you see a bug, you can fix it. But, to get a fix into a release, we have 2 (simple) requirements: 1, before it can go into a future 1.6 release, the fix must have an associated bug number in our bug tracking system, and 2, it must be reviewed by someone other than the person who committed the fix. The way this has worked so far is, before we do a release, we go through bugzilla and look for anything that's marked[3] as the "future 1.6" milestone, and has been closed but not verified. For each bug, we look at the commit in the 1.6-testing branch, test it if it's anything but a trivial one-liner, and merge it to the 1.6 release branch, then mark it as verified. It's a bit tedious, but I love that we know everything that's gone into a release[4]. As part of our scrum-ban process, merging will be another task that we'll regular schedule in our backlog along with development work, so we don't build up all that merging at release time. Nightly 1.6 snapshots will be more timely, and features should be pushed through the development process faster, instead of trying to juggle too many things simultaneously. 1. 2. 3. 4. Upcoming Events --------------- * October 28, 2009: Tarus Balog will be speaking at the Open Source Monitoring Conference 2009 in Nuremberg. If you have anything to add to the events list, please let me know. Until Next Week... ------------------ As always, if there's anything you'd like me to talk about in a future TWiO, or you just have a comment, criticism, or whiteboard management tools you'd like to share, don't hesitiate to say hi. -- Benjamin Reed The OpenNMS Group ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! _______________________________________________ Please read the OpenNMS Mailing List FAQ: opennms-announce mailing list To *unsubscribe* or change your subscription options, see the bottom of this page:
