1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
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.
|
