You are here

LCFG client refactor - code cleanup

Project ID: 
Current stage: 


The aim of this project is to cleanup up the code of the LCFG client
(primarily rdxprof). This will not be a complete rewrite and we do not
intend to add new features. The project will however go beyond basic
refactoring by addressing a couple of longstanding bugs which have
been seen to regularly cause problems for users. The aim is to bring
the code up to "Modern Perl" standards and make it more portable.

Note that completely redesigning the code (such as reimplementing
using a proper Object-Oriented framework like Moose) is outside of the
scope of this project.

This is expected to require 4 weeks effort, the project has been split
up into 11 tasks with 19 days allocated which leaves 1 day of
leeway. Time allocations for tasks have been rounded up to the nearest
half day of effort, some will take less, some might take more. For
some of the tasks the changes might be quite small but a good
understanding of the code will need to be acquired first.

This is a child project of project 139

Deliverables: Cleaner LCFG client component code


Customer: Internal

Case statement: There is a significant risk that the existing code base might not run "as is" on future DICE platforms. Further developments of LCFG are also stalled because of the difficulty of extending the existing code.








Resources: Four weeks.


1. Rework the rdxprof script as a Perl module. (0.5 days)

This makes the code more manageable and potentially reuable, it also
allows the creation of a code-level test suite for the various
subroutines. This will reduce the risk involved in future development
and maintenance. The rdxprof script will still exist but will just
call functions from the new module (a similar approach was taken with
the LCFG server mkxprof script).

2. Basic test suite (0.5 days)

Add basic compilation tests for all modules which can be run each time
the package is built.

3. Run code through perltidy (1 day)

This will make the code indentation and formatting more consistent and
thus more readable. It will be done to the same rules as the LCFG
server code base.

4. Refactor code to satisfy perl critic level 5 (2 days)

This stage will refactor the code to deal with the worst cases of
badly written Perl based on the findings of the perlcritic tool.

5. Refactor code to satisfy perl critic level 4 where possible (2 days)

This stage will refactor the code to eliminate the majority of the
lesser code issues. The experience of improving the LCFG server code
showed that it is not entirely possible to satisfy level 4. There are
likely to be some cases where it is essential to implement
functionality in a way which might not be considered "best practices".

6. Enable 'warnings' and eradicate any use of undefined variables (4 days)

None of the LCFG client modules or the rdxprof script have the Perl
warnings pragma enabled. We should enable this in all code to avoid
nasty surprises. Based on the experiences of refactoring the LCFG
server code this is likely to result in a substantial number of
warnings being generated related to the usage of undefined
variables. Eradicating this use of undefined variables is likely to be
the biggest part of the project, in particular, finding them takes
quite a bit of effort when they lie in uncommonly used code paths. It
also requires a good working knowledge of the code to understand when
there is a specific meaning attached to a variable being in an
undefined state.

7. Improve option handling (1 day)

The current handling of command-line options in rdxprof is fairly poor
and does not support the longer descriptive option name style. It
would also be very useful to add support for a simple configuration
file. This would make it easier to separate the client code and the
LCFG component into separate projects in SVN.

8. Eradicate hard wired paths (1 day)

There are a number of paths hardwired into the code using the CMake
macro syntax (e.g. @FOO@). This means it is currently not possible to
run rdxprof unless you are the root user, even if you can read the XML
profiles. They should all be converted into command-line options with
the current values being the defaults for root and new defaults being
introduced for the non-root user scenario. These macros also need to
be removed so that we can convert the code into a standard Perl

9. Split client and LCFG component (1 day)

The LCFG client code should be split out into a separate project in
SVN. This would allow the packaging to be reworked so that it is
buildable as a standard Perl module which can be submitted to
CPAN. The LCFG component would still be built as normal using the
CMake based system.

This follows the way in which the LCFG server code is packaged. It
should be relatively straightforward, and can reuse the Module::Build
module created for that package.

10. Bug Fix: Rework the network port handling (4 days)

On startup the client attempts to listen on a network port so that it
can receive signals from the server when a new profile is
available. If the port has already been taken by another process then
the client hangs forever. This is particularly undesirable behaviour
as it leaves a machine in an unmanageable state, we should rework this
code so that it fails better. The client should be able to just log
the error and carry on. There is no issue with continuing without the
ability to listen for notifications since the client will still be
able to regularly poll the server for changes, the responsive will
only be slightly degraded.

11. Bug Fix: Regularly lookup the addresses for servers (2 days)

Currently, once the client has looked up the address for a server it
continues to use that address until the process is restarted. This
makes it very difficult to move a server (for instance, by just moving
a DNS CNAME from one host to another). This data should be stored in a
time-limited cache so that lookups are redone occasionally.





Proposed date Achieved date Name Description