/[i-scream]/projects/cms/documentation/minutes/minutes-20000928.txt
ViewVC logotype

Contents of /projects/cms/documentation/minutes/minutes-20000928.txt

Parent Directory Parent Directory | Revision Log Revision Log | View Revision Graph Revision Graph


Revision 1.1 - (show annotations)
Wed Oct 25 18:05:02 2000 UTC (18 years, 6 months ago) by tdb
Branch: MAIN
CVS Tags: PROJECT_COMPLETION, HEAD
File MIME type: text/plain
Minutes from meeting on 28/09/2000.

1 Minutes of Meeting, 29/09/2000 @ 14:30
2 Location: Computer Science Building UKC
3
4 Group Members Present: ab11, ajm4, pjm2, tdb1
5 Staff Members Present: jc (initially), pssc (initially),
6 iau (latterly)
7 Absent: none
8
9 The initial stage of the meeting was with John Cinnamond
10 (the setter of the project). During this part of the meeting
11 general requirements of the proposed system were discussed.
12 The details of these requirements follow.
13
14 Systems that will need to be monitored software:
15 - Solaris, NT, maybe Linux (jc)
16 - maybe FreeBSD (group)
17 Information that should be monitored & gathered:
18 - Backups – do they complete?
19 - Swap space – is there enough?
20 - Memory – is there enough?
21 - Load – is it too high?
22 - Disk usage – is there enough?
23 Look at /var on certain machines
24 - Monitor individual users & processes,
25 e.g. monitor for a day specifically
26 - tracking
27 - Log file collation
28 – easy viewing and notification of messages in logs
29
30 Alerting system:
31 - Priorities of alerts
32 – what escalation each alert should have
33 - Alerts – must be easily viewable and configurable
34 - Grouping contacts for notification
35 - Easy to cancel warnings & alerts
36
37 - Methods:
38 - Beeps
39 - E-mail
40 - Webpage
41 - Maybe pager or sms
42
43 Information reporting:
44 - Email
45 - Web
46 - Small desktop applications
47 - Graphs of data
48 - Roll back logs
49 - Public monitor pages for everyone to look at
50 – overviews of machine status
51
52 Implementation notes:
53
54 John Cinnamond informed the group that he would be able to
55 supply a test machine possibly more than one, should the
56 need arise. Must be well written software, as the time when
57 it will be needed most, will often be when a system is very
58 tight on memory or has a high load. And they themselves
59 must not crash the system. Must be able to throttle data
60 sent (maybe UDP), so as not to flood bandwidth and to set
61 how much information is sent and how frequently. System
62 shouldn’t give up after one failed test, it should retry
63 tests with maybe levels of warnings, before reporting a
64 failure – again, this should be configurable. Note that
65 some systems are spread across multiple machines e.g. raptor
66 file store.
67
68 - Don’t user kernel data structures, always use APIs as they
69 will be much more efficient.
70 - Start small, aim for extendability and scalability.
71 - Ensure ease of configuration through a text file or a GUI,
72 specifically quick adding and removing of hosts.
73 - Solaris is the most important platform then NT & Linux.
74 - On NT systems you won’t be able to monitor “load” in the
75 unix sense, just CPU usage – which is expected to be low.
76
77 It was noted that the system will be very useful to them and
78 that we should use John Cinnamond for any technical queries
79 about implementation. It was left that we should produce a
80 requirements document draft for John Connamond to review
81 before proceeding any further. These minutes will be used
82 as the basis for an initial draft of the requirements.
83
84 The latter stage of the meeting was with Ian Utting, the
85 project supervisor for the group. It was noted that the
86 first stage was to review technologies and strategies to
87 determine what is needed to get the project underway. This
88 includes determining what process the group will follow, as
89 there are no “proper” methods useful to every project. The
90 group should determine the right process for the project.
91 Ian Utting suggested the use of an “Audit Trail”, a method
92 of recording the discards of ideas and why, the changes, the
93 ideas and also the bad ideas that the group have chosen. The
94 group was informed that a plan should be submitted early on
95 i.e. who, what, when - of how the system will be developed.
96 This plan can then be revised to include what we actually
97 did, for when the project is submitted. The group should
98 spend no more than a maximum of 1.25 days per week on the
99 project in order to allow for other university work. Each
100 member will need to present a talk for 15mins, for which the
101 group needs to devise a presentation, by then should have a
102 rough plan of timetable, ideas and requirements for the
103 system. A regular meeting time was set with Ian Utting and
104 the group. There will also be occasional meetings with John
105 Cinnamond. This regular meeting will be:
106
107 Every Wednesday – 14:00 to 15:00
108
109 Technologies to consider were also discussed, these included
110 Jini, SNMP, XML. Specifically the Jini Java technology
111 which may allow for some quite functional and maintainable
112 code for presenting the interface to the system. When
113 discussing these subjects Ian Utting suggested making a case
114 for why any particular design should be used and determining
115 which is better through group discussion. It was also
116 recommended that the group look at other products that
117 perform similar functions, build a tick list of features
118 and requirements and decide which should be considered for
119 inclusion in the project system. The key thing to remember
120 will be to prioritise requirements ensuring that the
121 “extras” are left till last.
122
123 The following tasks were listed for the group to look into
124 over the next week:
125
126 - Produce minutes of today’s meeting
127 - Start drafting milestones and requirements
128 - Look into central location for documents and templates
129 – i.e. a website
130 - Look into technologies, get URL’s and other references to
131 information
132 - Look into CVS for document and code storage and version
133 control
134 - Brainstorm ideas
135 - Setup a mailing list for ease of communication within the
136 group
137 - Think of a name and logo for the project
138 - Find out our filespace information for the project
139 – e-mail cs-sysadmin

  ViewVC Help
Powered by ViewVC 1.1.26