Monthly Archives: September 2016

5000 downloads of 0.98, and progress on 0.98a

Weathermap 0.98 hit 5000 downloads yesterday… woo!

Also, work is going well on the database changes for 0.98a. The actual database stuff has all been replaced and about 70% tested. Some of the other changes have highlighted some issues though, so I’m working on those now. The solution has been to pull in some of the refactored code from last year, which is tricky in places – it is all interdependent, so you have to try and break bits off cleanly. So now I am working through, weaving the two parts back together again.

Anyway, the end result will be some nicer code that most people won’t care about, and PHP 7 working, which they will! I don’t plan on this taking a lot longer, spare time permitting.

Making Weathermap “really” open source

6 Replies

Although Weathermap has always been available under the GPL, you could reasonably argue that it’s not really open source. The reason it’s GPLed is simply that it was originally written in perl, based off of GRNET’s perl Weathermap, way back at the end of 2004. When I got tired of explaining how CPAN works (to install the perl GD module and dependencies) and switched to PHP, I kept the same license.

Despite being GPLed for 10 years, there have been very few code contributions. I can see why – it’s a fairly big tangled mess of PHP, considering the relatively simple job it does. It was my first PHP application from scratch too, and has lived long enough to be partly PHP 4 and partly PHP 5 style. Even if you do make the effort to read it all, you’ll find it has a few “god objects” which make modification harder than it needs to be. So effectively, it’s a personal project that you could re-use if you really wanted to.

Also the number of users – network engineers, mostly – who can and want to code is pretty small. I don’t want to discourage the few that remain!

Having worked a little on other “real” open source projects, I really want to change this. For example, when I had an issue with beets, I was able to submit patches, get useful feedback from the project lead, and eventually get my change into the next release. It felt good, was collaborative, and solved my problem permanently too. That’s the kind of experience I want for Weathermap.

The first steps towards this have already happened – moving from subversion to github gets us the infrastructure to do Pull Requests, which is very powerful. There are the beginnings of unit tests, and more on the way as new code is added, to hopefully get to the stage that any PRs can be tested automatically using TravisCI. The code quality is (slowly) improving, and the ‘master’ branch on github has the results of some refactoring already. It may be that only some of that work makes it into a release, but the goal is to get to more and smaller classes, much reduced global variable usage and documented classes!

I have been using CodeClimate to highlight areas to work on, mostly for removing complexity and duplication so far. For example, processing of data source targets in the refactored version is a lot cleaner. Also, as UI code is moved into classes, it makes that easier to test too, which is a big gap currently – the image generation side of things has hundreds of tests. Similarly, there are Vagrant configuration files to automatically produce test environments on 10 or so difference Linux distros.

At the moment, things are still moving around, but once the next couple of releases are complete, I’ll be working on bringing the ‘new’ version and the 0.97-maintenance branches back together, and hopefully have a working version with as much of the new code as possible. Parts (especially the Node class) are still too big and clunky, but there is some useful work already done.

With that in place, I hope we can have a really open source network visualisation tool!

September 2016 – Current issues

1 Reply

Just a quick note about known current issues with Weathermap 0.98:

It doesn’t work with PHP 7.0 – In PHP 7.0, the ancient mysql_xxxxx() functions that WM uses for database access are no longer available. The rest of the world moved on to PDO some time ago, but I didn’t bother because Cacti didn’t. PHP 7.0 is the default in some distros now (Ubuntu 16 at least) though, which makes it a bigger problem. I’m in the process (about 70% through) of fixing this by replacing all the database access code. This has some other benefits for the future, like the possibility of supporting other databases, and better database security (I’m moving to prepared statements everywhere too). I’m also separating out the actual database stuff from the Cacti plugin, so writing a plugin for something else should be easier too. The editor and command-line tool don’t use a database currently, so those are not affected.
(some of) It doesn’t work with PHP 5.3 – Well, this is embarrassing! In fixing a deprecated code issue for PHP 5.6+, I added a problem for PHP 5.3. Luckily it’s a one-line fix, and only affects the command-line ‘weathermap’ tool. If you get PHP Parse errors with 0.98 and PHP 5.3, here is the solution until 0.98a comes out.

Photo Credit: Wisconsin Department of Natural Resources

Links between maps

Introduction

Links between maps, and links to other sites are often requested as ‘new features’, even though they are already possible. Here are the things you need to know:

Any node or link can have a URL associated with it, using the INFOURL keyword. Usually, this is a link to a Cacti graph or something similar, but it doesn’t have to be.
A node doesn’t have to represent a router or device either.
For Cacti in particular, the ‘random’ ID in the weathermap name doesn’t ever change, and is safe to use in (HTML) links.

Simple version

So, putting all that together:

NODE link-to-other-map
    POSITION 300 300
    LABEL Other Map
    INFOURL http://my-cacti-server/plugins/weathermap/weathermap-cacti-plugin.php?action=viewmap&id=4df1356edd3366055c5f

Will make a text link to your other map, using Cacti’s authentication to make sure you are allowed to see it. If you don’t use Cacti, this would just be the URL for the other map as you see it in the browser.

Fancier version

How about having a thumbnail of the other map that you can click on?

As long as both maps are on the same Cacti server, Weathermap already generates a thumbnail to use in the web interface, which you can use too.

Some things you need to think about though: Weathermap updates the maps in the order they are listed in the management page, including the thumbnail updates. So if you want to be sure of getting the latest thumbnail, your master top-level map should be the last one in the list. You can put it in its own group though, so it isn’t all the way down a page of maps, and Weathermap remembers which group you last clicked on, so that shouldn’t be a problem either.

NODE link-to-other-map
    POSITION 300 300
    LABEL Other Map
    ICON 64 64 output/4df1356edd3366055c5f.thumb.png
    INFOURL http://my-cacti-server/plugins/weathermap/weathermap-cacti-plugin.php?action=viewmap&id=4df1356edd3366055c5f

So now we are using the thumbnail image as the icon for our node, and also telling Weathermap to scale it down so that it fits in a 64×64 pixel box.

Final Notes

The only real limitations are that you can’t use a URL for an ICON (this is possible with PHP, but not enabled on all installations. Also, try to avoid using the icon scaling to scale full-size images down to thumbnails, if you are concerned about performance (like updating a set of maps once per minute).

New Site

Survey results: this blog!

Network Weathermap

Open Source Network Visualisation