[169] in Athena_Backup_System
Re: reminder: please review this
daemon@ATHENA.MIT.EDU (dkk@MIT.EDU)
Thu Jan 11 13:30:09 1996
From: dkk@MIT.EDU
Date: Thu, 11 Jan 1996 13:30:02 -0500
To: delgado@MIT.EDU
Cc: athena-backup@MIT.EDU
In-Reply-To: <9601111626.AA02270@green-acres.MIT.EDU> (message from Diane Delgado on Thu, 11 Jan 1996 11:26:25 EST)
Since I won't remember all this until the meeting, I'm emailing my
comments on the error routing section.:
> The configuration information will be implemented as a table in the
> Oracle database with the following definition:
Using a DBMS for a table that really has only one column (pool) in
common with the rest of the DB may be viewed as gratuitous use of
advanced technology where a text file could be easier for the
customer. I don't really care (since each Oracle and a text file have
certain advantages here) but be prepared for complaints from others in
Operations, since those who care would probably prefer a text file.
This isn't just the same "to DBMS, or not to DBMS" question, because
there is little DB advantage to having the table in the same database
as everything else (though I'm sure it makes the code a lot cleaner).
> destination & varchar(64) & to whom the message shall be delivered
64 seems awful short. This table will have so few records, the field
size isn't a big deal. I'd prefer varchar(128) or varchar(256).
> error class, then the ABS will use both delivery methods for error
s/both/all appropriate/ (could be more than two)
If we wanted to configure it to zwrite Zephyr class ops, instance
abs-error, and also to send a personal zgram to user "dkk", how would
we configure that? Two separate records?
> notification. As previously mentioned, if no delivery method is
> specified for an error class, then errors will be redirected to
> the initiator using e-mail.
How does it determine the email address? From the Kerberos principal?
Backing up a bit:
> \item {\bf paging} - use a command which interfaces with a paging
> service for notification. Use of such a service would be restricted
> to messages of the type {\it ABS\_FATAL};
Did you mean ABS_CRITICAL?
The restriction to only fatal errors seems pretty arbitrary, as we all
use our pagers differently, and there are people who would want to
know about fatal errors with any class, but not about mundane errors
(ABS_ERROR) at all via a particular delivery method. Would it be much
trouble to add a "severity rating" field to the configuration?
Finally, here are some nit-picky corrections:
> configureable on a per-pool basis. Errors classes for which
s/Errors/Error/
> \item {\bf ABS\_WARNING} - The system is able to workaround such
s/workaround/work around/ ("workaround" is a noun)
> problems, such as truncating the name of a volume which is too long.
s/such as/such as by/
> functioning of the system are alway logged to syslog and the
s/alway/always
s/to syslog/via syslog/
> tape mount requests, media errors, wrong tape mounted, tapes
s/mounted, tapes/mounted, and tapes/
> which prevent database access or updates from ocurring. Such
s/ocurring/occurring/
> problems include failure to rollback transactions, database
s/rollback/roll back/ ("rollback" is a noun)
> which prevent the master from functioning properley. Errors of
s/properley/properly/
> only for completeness
s/ness/ness./ (missing period)
--
David Krikorian, dkk@mit.edu, KA1NAP; MIT/IS/DCNS/Ops, APO, LSC, SIPB
