i-scream documentation viewer
minutes-20000928.txt
Minutes of Meeting, 29/09/2000 @ 14:30
Location: Computer Science Building UKC
Group Members Present: ab11, ajm4, pjm2, tdb1
Staff Members Present: jc (initially), pssc (initially),
iau (latterly)
Absent: none
The initial stage of the meeting was with John Cinnamond
(the setter of the project). During this part of the meeting
general requirements of the proposed system were discussed.
The details of these requirements follow.
Systems that will need to be monitored software:
- Solaris, NT, maybe Linux (jc)
- maybe FreeBSD (group)
Information that should be monitored & gathered:
- Backups – do they complete?
- Swap space – is there enough?
- Memory – is there enough?
- Load – is it too high?
- Disk usage – is there enough?
Look at /var on certain machines
- Monitor individual users & processes,
e.g. monitor for a day specifically
- tracking
- Log file collation
– easy viewing and notification of messages in logs
Alerting system:
- Priorities of alerts
– what escalation each alert should have
- Alerts – must be easily viewable and configurable
- Grouping contacts for notification
- Easy to cancel warnings & alerts
- Methods:
- Beeps
- E-mail
- Webpage
- Maybe pager or sms
Information reporting:
- Email
- Web
- Small desktop applications
- Graphs of data
- Roll back logs
- Public monitor pages for everyone to look at
– overviews of machine status
Implementation notes:
John Cinnamond informed the group that he would be able to
supply a test machine possibly more than one, should the
need arise. Must be well written software, as the time when
it will be needed most, will often be when a system is very
tight on memory or has a high load. And they themselves
must not crash the system. Must be able to throttle data
sent (maybe UDP), so as not to flood bandwidth and to set
how much information is sent and how frequently. System
shouldn’t give up after one failed test, it should retry
tests with maybe levels of warnings, before reporting a
failure – again, this should be configurable. Note that
some systems are spread across multiple machines e.g. raptor
file store.
- Don’t user kernel data structures, always use APIs as they
will be much more efficient.
- Start small, aim for extendability and scalability.
- Ensure ease of configuration through a text file or a GUI,
specifically quick adding and removing of hosts.
- Solaris is the most important platform then NT & Linux.
- On NT systems you won’t be able to monitor “load” in the
unix sense, just CPU usage – which is expected to be low.
It was noted that the system will be very useful to them and
that we should use John Cinnamond for any technical queries
about implementation. It was left that we should produce a
requirements document draft for John Connamond to review
before proceeding any further. These minutes will be used
as the basis for an initial draft of the requirements.
The latter stage of the meeting was with Ian Utting, the
project supervisor for the group. It was noted that the
first stage was to review technologies and strategies to
determine what is needed to get the project underway. This
includes determining what process the group will follow, as
there are no “proper” methods useful to every project. The
group should determine the right process for the project.
Ian Utting suggested the use of an “Audit Trail”, a method
of recording the discards of ideas and why, the changes, the
ideas and also the bad ideas that the group have chosen. The
group was informed that a plan should be submitted early on
i.e. who, what, when - of how the system will be developed.
This plan can then be revised to include what we actually
did, for when the project is submitted. The group should
spend no more than a maximum of 1.25 days per week on the
project in order to allow for other university work. Each
member will need to present a talk for 15mins, for which the
group needs to devise a presentation, by then should have a
rough plan of timetable, ideas and requirements for the
system. A regular meeting time was set with Ian Utting and
the group. There will also be occasional meetings with John
Cinnamond. This regular meeting will be:
Every Wednesday – 14:00 to 15:00
Technologies to consider were also discussed, these included
Jini, SNMP, XML. Specifically the Jini Java technology
which may allow for some quite functional and maintainable
code for presenting the interface to the system. When
discussing these subjects Ian Utting suggested making a case
for why any particular design should be used and determining
which is better through group discussion. It was also
recommended that the group look at other products that
perform similar functions, build a tick list of features
and requirements and decide which should be considered for
inclusion in the project system. The key thing to remember
will be to prioritise requirements ensuring that the
“extras” are left till last.
The following tasks were listed for the group to look into
over the next week:
- Produce minutes of today’s meeting
- Start drafting milestones and requirements
- Look into central location for documents and templates
– i.e. a website
- Look into technologies, get URL’s and other references to
information
- Look into CVS for document and code storage and version
control
- Brainstorm ideas
- Setup a mailing list for ease of communication within the
group
- Think of a name and logo for the project
- Find out our filespace information for the project
– e-mail cs-sysadmin
