This Week in OpenNMS: The Honeymoon Isn’t Over

by Benjamin Reed: April 13, 2010

It’s time for This Week in OpenNMS. This week we hit a milestone in the SMS work, made it through our first week of scrumban, and started work on a number of map-related enhancements.

Project Updates

  • Stable: Current Release is 1.6.6
    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 wrapped up the last few tasks for the first milestone of the SMS pinger. You can attach multiple modems to the OpenNMS system, and perform SMS and USSD “sequences” much like the page sequence adapter for HTTP. We started with a number of interesting use cases:

    • SMS ping: send a “ping” SMS message from one phone to another. That phone will respond with “pong” and the latency of that transaction will be stored.
    • Carrier balance check: Send a message asking for balance, receive back a balance from the carrier.
    • Minute “gifting”: Send a USSD message gifting minutes to another phone. Expect a response from the carrier asking for confirmation. Send “1” to confirm that we want to gift minutes, and then receive a confirmation from the carrier.

    There will probably be lots of other interesting uses for it, now that the infrastructure is there.

  • Unstable: Map Link Enhancements
    We also started work on another development project we’ve been contracted to do, relating to various map enhancements. This week we got the basic specification done, and started work on coding. The goal, among other things, will be to be able to query link status of a certain class of devices, and update the map in real-time with the status of those links.
    We’ve finished the configuration file format, updated the link model to not require an SNMP interface for links between nodes, updated the map UI to handle displaying link status changes, and written the infrastructure to deal with data link up/down events.
  • Unstable: Logging Updates
    Dave did some work finally unifying our logging’s schizophrenic use of stderr/stdout and log4j. He created an adapter for the log4j logger which will capture stdout and stderr so output.log will no longer grow out of control.

OGP Conference Call

Last week we had a virtual OGP summit conference call over Skype, where we talked about things we wanted to do in the coming year from a community point of view.
First we here at The OpenNMS Group talked about our current status. Despite a slow start, we’re having a record year, and have almost more work than we know what to do with. We’ve contracted some work to help with the load, and are bringing at least one more person on before the end of the year.
The next item on the agenda was having another user conference. The first OpenNMS User Conference was a big success, and we’re looking to grow it this year. The main question is do we do it again in Europe, or try to move to North America? Some folks volunteered to investigate the options, and we’ll let everyone know when we know ourselves what’s planned.
After that, we talked about managing community contributions, and keeping feature branches from going out of date. At that point I had to leave the call, so I missed the rest. I’ve asked the OGP for a summary of what else was discussed, but didn’t hear back at the time of TWiO publication. I’ll continue this next week. :)

Scrum-Ban, Week Two

So we made it through our first week of scrum-ban, and I have to say, I’ve managed to still be excited about it. ;) We got a ton of tasks done for our various custom development obligations, and we’ve already hit some of the issues that scrum-ban is great at exposing.
For example, we came in today to do our weekly status and the current scrum-ban board shows that we can’t really move anything out of the development stage even if they’re finished, because we haven’t finished testing the DNS provisioning service and SMS sequence monitor, and we’re only allowed to have 2 things in the “test” phase.
What does this mean? Rather than trying to do more task work that would just plug up development, we’re focusing on testing existing (finished) features (“stories”) and moving them through the process. This means that finished features will actually get into a released state much faster, which means you guys get to play with them sooner.
Another thing we decided is that we’re going to move to a time-based release schedule. Since we are tracking features more closely through the development process, and actively testing more (rather than a combination of personal testing and “let the community play with it in snapshots” testing) we can be more confident that the kinks will be worked out. You’ll note in that image that there’s a grey sticky in the lower-right documenting the next release as October 5th, 2009. On that day we’ll release 1.6.7 and 1.7.7 (unless an emergency blocker bug forces an early release, of course…) and then schedule another release on the first monday of December.
Of course, the biggest thing you’ll notice is that we actually have an image that shows you our current scrum-ban status. Since many of us work from home, or travel, it made sense to make our “whiteboard” available somewhere online. And, in the spirit of default to open, there is no reason folks in the community shouldn’t see that status as well, and for that matter, pick up a task if you really want to jump in.
You can keep up with the scrum-ban status at any time by going to — and if you have any suggestions,
please don’t hesitate to let us know. The goal for this process is for us to get the features we’re working on to you (faster!) and to make it easier to balance our obligation to customers contracting custom development with our obligation of making sure that OpenNMS stays up-to-date and quality software that the community can get the most out of.
There are, of course, many bugs to fix as well, and we will be making it a part of the process to have regular stories for taking care of “code debt” — refactoring, bugfixes, etc. that aren’t necessarily new features.

Upcoming Events

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 bulk virtual stickies for our virtual whiteboard you’d like to share, don’t hesitiate to say hi.

Tags: , , , , , , , ,

Stay Connected

Subscribe to this site and get the latest project and event updates

Subscribe via RSS
  • Facebook
  • Twitter

OpenNMS Site Archives