What’s new? During recent weeks we’ve been coding and performing several changes to Citellus and Magui. Checking the latest logs or list of issues open and closed on github is probably not an easy task or the best way to get ‘up-to-date’ with changes, so I’ll try to compile a few here. First of all, we’re going to present it at DevConf.cz 2018, so come stop-by if assisting :-) Some of the changes include… ...
Introduction In order to improve Citellus and Magui, we did implement some Unit testing to improve code quality. The tests written were made in python and with some changes it was also possible to validate the actual tests. Also, we did prepare the strings in python using gettext library so the actual messages can be translated to the language of choice (defaults to en, but can be changed via --lang modifier of citellus). ...
Why? While working on Citellus and Magui it soon became evident that Unit testing for validating the changes was a requirement. Initially, using a .travis.yml file contained in the repo and the free service provided by https://travis-ci.org we soon got https://github.com repo providing information about if the builds succeeded or not. When it was decided to move to https://gerrithub.io to work in a more similar way to what is being done in upstream, we improved on the code commenting (peer review), but we lost the ability to run the tests in an automated way until the change was merged into github. ...
Background Citellus allows to check a sosreport against known problems identified on the provided tests. This approach is easy to implement and easy to test but has limitations when a problem can span across several hosts and only the problem reveals itself when a general analysis is performed. Magui tries to solve that by running the analysis functions inside citellus across a set of sosreports, unifying the data obtained per citellus plugin. ...
Background Since I became Technical Account Manager for Cloud and later as Software Maintenance Engineer for OpenStack, I became officially part of Red Hat Support. We do usually diagnose issues based on data from the affected systems, sometimes from one system, and most of the times, from several at once. It might be controllers nodes for OpenStack, Computes running instances, IdM, etc In order to make it easier to grab the required information, we rely on sosreport. ...