Subject: Re: Sched/Script MIB issues

From: Alan Luchuk <[email-masked]>
Date: Thu, 6 Jan 2000 10:19:02 -0500 (EST)

Hello all,

>Alan> Issue Script-02:
>>>>> o Restartable scripts
>>>  Scripts that are automatically launched when an agent starts up
>>> (or some other event happens).
>
>Alan> I believe Eamonn has a simple and elegant solution for launching
>Alan> scripts when the DISMAN-SCRIPT-MIB agent starts.  If the
>Alan> smLaunchName begins with an asterisk, the corresponding launch
>Alan> 'button' is pressed automatically when the agent starts.  I have
>Alan> added this to SNMP Research's DISMAN-SCRIPT-MIB implementation.
>
Juergen>Not sure I really like this solution. I understand that it is easy to
Juergen>implement. A cleaner solution would IMHO be to have the autostart bit
Juergen>encoded somewhere else. One could for example define a BITS object
Juergen>which has a bit set if the launch butten should be pressed by a
Juergen>restart event. A BITS object also allows to add additional flags over
Juergen>time without playing even more games with the name. The other ultimate
Juergen>solution is to define a mechanism which allows to launch scripts (or
Juergen>better perform sets on INTEGER valued objects) when a notification is
Juergen>generated or received. But this gets hairy when it comes down to
Juergen>passing notification details to the script or whatever got invoked.
Juergen>
Juergen>So I currently tend to prefer an object which indicated autostart
Juergen>behaviour and to leave a more general mechanism for future work (which
Juergen>would be a nice small MIB module independent from the schedule MIB
Juergen>itself).

I can align with whatever the DISMAN WG group decides is the best way to
handle the auto-start issue.  I implemented Eamonn's auto-start solution 
because it was way simpler and more elegant than what I devised.

>
>Alan> Issue Script-03:
>>>>> o Error message during script retrieval or compilation
>>>>> (smScriptError)
>>>  So you argue in favour of adding such an object. Do you have a
>>> concrete proposal for the definition of such an object?
>
>Alan> I suggest adding a single octet string MIB object to the
>Alan> smScriptTable that can return compile-time error messages.  This
>Alan> would provide a single-line error message that would describe
>Alan> the first compile-time error that occurred.
>
>Alan> Other solutions are possible, like a _table_ of octet strings
>Alan> that would describe all compile-time errors that occurred.
>
>Alan> SNMP Research's DISMAN-SCRIPT-MIB implementation would work just
>Alan> fine with a single-line error message, but I can see the value
>Alan> of an error message table.
>
>Alan> Based upon the preferences of the DISMAN WG for one or the other
>Alan> of these solutions, I'll be glad to write up first-cut additions
>Alan> to the DISMAN-SCRIPT-MIB.
>
>I would prefer a single object to keep things small. I think it should
>be an SnmpAdminString or do we really care about binary data?

OK.  Based on a lone voice crying in the wilderness, would it make
sense to add the following to the smScriptTable:

   smScriptCompileMessage OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "Contains any single message produced during script compilation."
       ::= { smScriptEntry 10 }

(It will be left to the astute reader to determine whether or not
this was shamelessly cut-and-pasted from the smScriptDescr.)

Would it also make sense to put in another MIB object the smScriptEntry
that indicates the severity (e.g., like 'informational', 'warning', 
'error', and 'fatal') of the smScriptCompileMessage?

Regards,
--Alan
 
 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 865 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 865 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.snmp.com/
 -----------------------------------------------------------------------------

   Please note that our telephone area code recently changed from 423 to 865. 
   Area 423 should countinue to work until it is phased out in April, 2000.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Jan 2000 16:36:48 +0100

>>>>> Alan Luchuk writes:

Alan> OK.  Based on a lone voice crying in the wilderness, would it
Alan> make sense to add the following to the smScriptTable:

:   smScriptCompileMessage OBJECT-TYPE
:       SYNTAX      SnmpAdminString
:       MAX-ACCESS  read-only
:       STATUS      current
:       DESCRIPTION
:           "Contains any single message produced during script compilation."
:       ::= { smScriptEntry 10 }

Alan> (It will be left to the astute reader to determine whether or
Alan> not this was shamelessly cut-and-pasted from the smScriptDescr.)

Why do you want to restrict this object to compilation errors? Would
it not make more sense to have something like the following:

smScriptErrorMessage OBJECT-TYPE
    SYNTAX	SnmpAdminString
    MAX-ACCESS	read-only
    STATUS	current
    DESCRIPTION
	"This object contains a descriptive error message whenever
	 the corresponding smScriptOperStatus variable indicates
	 a non-transient error state.

	 This object must be cleared whenever the value of
	 smScriptOperStatus changes to one of the values `enabled',
	 `disabled', `editing', `retrieving', or `compiling'."
    ::= { smScriptEntry 10 }

This way, the object can also hold a descriptive error message in
cases such as a failed download (e.g. protocolFailure).

Alan> Would it also make sense to put in another MIB object the
Alan> smScriptEntry that indicates the severity (e.g., like
Alan> 'informational', 'warning', 'error', and 'fatal') of the
Alan> smScriptCompileMessage?

I originally did not think of 'informational' or 'warning'
messages. But we can probably allow them in case you reach the
`enabled' state. Not sure we really should go down the path to try to
classify these messages.

In other words: a distinction between 'informational'/'warning' and
'error'/'fatal' is already in place (smScriptOperStatus). Not sure we
really need more since the precise distinction between these levels
will really be implementation dependent, I think.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>