[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf A non-trivial policyAction example




>>>>> Steve Waldbusser writes:

Steve> This API won't work in our environment because agents don't
Steve> have MIB compilers and therefore don't know the type of a
Steve> variable. For example, in the maxDesiredEntries varbinds above,
Steve> it's not clear whether to send the integer 1000 or the 4
Steve> character string "1000".

Sure, I can write the same script using OIDs and having type
information in there as well. The Tnm API allows you to do both.  I
decided to go with the short version since you used descriptors rather
than OIDs in your example as well. :-)

>> This example makes it very obvious to me that actions will be
>> complex over time and that a mechanism is needed to write
>> "procedures" (like the one above) which you can call and reuse in
>> actions. (I can easily imagine cases where a policy rule action
>> instantiates many rows and the hlMatrixControlEntry is just one of
>> them.)

Steve> Interesting, I had the opposite reaction. I was struck by the
Steve> fact that the function was well within a manageable size and
Steve> that no functional decomposition seemed obvious.

We are working on a language which will have primitives on a much
higher level, e.g. a primitive to 'ensure that the following row
exists in a table'.  Your code (and my code as well) was more part of
the assembler code for what I consider to be a primitive in a decent
policy language. But I know, we have different opinions on this.

>> The fix is flawed as well since the oid in the scratchpad does not
>> say which SNMP agent the action is executed on.

Steve> This is handled automatically by the execution environment
Steve> which knows the address of "this element".

Address? EngineID? EngineID + ContextName? Is it specified anywhere
what it is?

>> I am also concerned about the error handling - what happens if
>> e.g. snmpsend(0, 5, OP_SET); fails with an SNMP error? Will the
>> policy repeat in a loop to fire this action regularily??

Steve> Yes, and I think this is desired behavior. A policy is trying
Steve> to enforce a certain behavior. If the enforcement fails
Steve> temporarily I think that it should continue to try. In this
Steve> case, the maxLatency won't be too high (maybe run once per
Steve> hour) and the (computational/operational) cost of failing is
Steve> low. In another circumstance where the cost of failing was
Steve> high, we could set something in the scratchpad to disable
Steve> enforcement on this interface.

There are errors where retrying simply does not make any sense (e.g.
a VACM configuration which does not give you access to the target).
Sure, it is much easier to ignore errors. But my experience is that
systems that ignore errors are not useful once something goes wrong.
Probably another point where we just have very different opinions.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  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/>