diff options
author | Patrick J Cherry <patrick@bytemark.co.uk> | 2012-11-27 16:12:50 +0000 |
---|---|---|
committer | Patrick J Cherry <patrick@bytemark.co.uk> | 2012-11-27 16:12:50 +0000 |
commit | fc996e815fe411cd79c553b6ec0b989f88d74806 (patch) | |
tree | d0696f9470e8743998e6a2a4a1464f39838a4dec /TODO | |
parent | 0d97c2393bec0c5ce27f26d1f48bb78af7c31ed8 (diff) |
Removed old TODO
Diffstat (limited to 'TODO')
-rw-r--r-- | TODO | 149 |
1 files changed, 3 insertions, 146 deletions
@@ -1,146 +1,3 @@ - TODO list for mauve - ---=== o O o ===--- - - -1 Unit test. -------------- - -We need a lot more. Currently, the testing is woefully inadequate. In -specific: - -1.1 test_cases.rb - - This needs a little work so that the tests in there run faster. The -test currently run in nearly four minutes which is too long. The -main problem appears to be the starting and stopping of the server. -Using a server for all the tests should work provided that we remove the -fake alert created by each test in the database in the teardown method. - - This could be linked to 2.3 - -1.2 The rest... - - Too many classes have no unit tests. This has to change. - - Everything new must have unit test associated with it. - - -2 Code refactor. ------------------ - - The idea here is to have a mauve server that receive new Alerts and -process them as state machines. A brain within this should determine -which Person gets a notification. This brain needs to be accessible via -the UI since events within the UI will impact the Alert -- such as -acknowledge events. - - The UI should be separate from the mauve server. The UI either needs -a hook into the backend database or send updated alerts. I prefer the -latter. - - -2.1 Timers class. - - This needs ripping out and replacing with event machine. - - -2.2 Alert class. - - This needs ripping out and replacing with a state machine. Something -like http://slagyr.github.com/statemachine/ maybe useful. - - A brain need creating as well. - - Mauvesend may need to be refactored to conform to the state machine -model. It should not be much work but will require major work to deploy -on all systems. - - This is lots of work. - - -2.3 Configuration class. - - Nothing here is essential but would be nice to have. - - This is fine but needs more error checking of the loaded configuration -file. - - A method to reload the configuration file gracefully -- aka without a -restart. This could be linked to 1.1. - - -2.4 UI, the web interface. - - This needs ripping out and separated as a new process. We can have a -thread in the main mauve server process write the date to a file every X -seconds. The UI can display this date and thus any check can be done on -that date. If it is older than X, then the main server has stopped and -we should alert everybody. - - - -3 General work. ----------------- - -3.1 Move to apt-ruby. - - We must get ride of the external directories and move fully to -apt-ruby. This should lead to better deployment on Debian. - - -3.2 Rubinius. - - Make sure we can run the code in Rubinius. Not urgent until the GIL -is fixed. Note that this may entails some new code for the XMPP -notification class. - - I tried to do this on Tue Jan 18 with rbx-head hydra (no GIL devel -branch) and it did not work well at all. The unit test ran slower than -with mri and failed on multiple occations (140 tests, 248 assertions, 0 -failures, 122 errors, 0 pendings, 0 omissions, 0 notifications 47.8571% -passed). I suspect rr mock and log4r gems are not playing well with -rbx as most errors were due to interactions between those two. It could -be that the rbx-head version is really not ready to be used in -production. - - -3.3 Documentation. - - We need some more in code documentation although it is now adequate. - - User documentation, especially with regards to the configuration file, -need a lot of work. Not sure where is the best: Redmine wiki, Bytemark -wiki, text file in repository... - - - - -4 New features. ---------------- - -4.1 XMPP/email interface. - - The ability to manipulate Alerts via XMPP and eamil. - - -4.2 Suppress Alerts. - - The ability to suppress alerts for a short time. - - -4.3 Notes for Alerts. - - The ability to create notes on alerts. - - -4.4 Better alert history. - - Either just cosmetic or require code changes to have a better timeline -of alerts status. - - -4.5 Really SMTP - - Move new smtp code so that we do not use the local mailer but send the -email directly. The code (with documentation and tests) is written but -not incorporated yet. +# +# Nothing to see here. +# |