Final report for the LCFG client refactor project (#225)

This project is the first stage in the LCFG Client Refactoring project - https://devproj.inf.ed.ac.uk/show/139

The aim of this sub-project was to clean up the code of the LCFG client in a similar way to the previous work on the LCFG server. The intention was to refactor the code into a "Modern Perl" style which is much more readable and maintainable.

As well as improving the code quality the API was fully documented and a higher-level guide was added so that other people could be involved in the development process. A new test suite was also creaed so that future developments can be done safely.

As well as refactoring the code we resolved several longstanding bugs. For example, the LCFG client now properly fails when it cannot acquire a network port rather than just hanging indefinitely. It can also now handle DNS lookup failures at start time and it notices if the IP address for a server changes.

The project had some other benefits such as the creation of a new Perl interface to om - LCFG::Om::Command - which makes it much easier to call methods on LCFG components from Perl code.

The biggest change was the introduction of the concept of the LCFG "node name". Previously we had always identified the client based on its host name (typically just the short name without any domain part). In most cases the two will be identical but there is now the possibility of them being different. This was introduced to support two use cases: roaming machines without a static address and multiple machines using a single LCFG profile. Some components needed code changes to handle this new feature, most of them have now been updated.

The project took 6 more days effort than originally expected. This can be almost entirely accounted for by the additional work we decided to do on altering the handling of the LCFG node name. This shows that taking a similar approach to the LCFG server refactor project was very sensible. The work of the two projects had many similarities (e.g. code size and quality). Breaking the plan down into lots of small manageable chunks (the largest was 4 days) also definitely helped, some chunks overran and some came in under budget but mostly it wasn't too far away from expectations at any point.

Most of the development work was done in a relatively short period during April and May 2013. I have no doubt that the most productive way to do this type of refactoring work is to be intensively focussed and get it done in the shortest possible period of time. Dragging it out over a period of many months would have been much less efficient since it would have required relearning the code base each time the work was restarted.

Given the importance of the LCFG client for the management of our infrastructure it's hardly surprising that the testing phase took several months before we were satisfied that it would not break anything. Since the launch of the beta release the code has not required much bug fixing. An issue was found with the rarely used "secure mode". A further issue was found which affected the setting of the node name during the install phase for machines where the domain of the client did not match the DNS search domain.

This work has provided an opportunity to gain a much better understanding of what functionality is provided by the LCFG client. There are currently a number of dark corners which are never used, we need to decide whether we want to continue supporting those features. There are also some features which are implemented in a rather sub-optimal way. For instance, the way the "oneshot" mode handles the downloading and processing of LCFG profiles which are not related to the current node has the potential to break installations in rare cases.

The redevelopment of the LCFG client has left it in a vastly improved condition. This will allow us to move forwards with further important work, such as the removal of the dependency on the ancient W3C modules which are used for parsing the LCFG XML profile. This should keep the client in a maintainable state for many more years. This allows Informatics and external users to confidently continue using LCFG to manage their infrastructure.

Timeline

  • Start - 29th March 2013
  • Most coding finished - 30th May 2013
  • Beta release - 16th October 2013
  • Deployed to DICE - 24th January 2014
  • Full deployed - 6th March 2014

Project diary - http://blog.inf.ed.ac.uk/squinney/tag/lcfg-client/

Effort

Period Hours
T1 2013 55
T2 2013 103
T3 2013 26

  • Expected effort - 20 days
  • Actual effort - 184 hours (26 days)

-- StephenQuinney - 26 Mar 2014

Topic revision: r2 - 31 Mar 2014 - 13:54:03 - StephenQuinney
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies