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

Re: snmpconf A non-trivial policyAction example

Juergen Schoenwaelder wrote:

> proc create_hlMatrixControlEntry {s ifIndex} {
>     if {[catch {setRowStatus hlMatrixControlStatus} index]} {
>         return
>     }
>     lappend vbl [list hlMatrixControlDataSource.$index ifIndex.$ifIndex]
>     lappend vbl [list hlMatrixControlNlMaxDesiredEntries.$index 1000]
>     lappend vbl [list hlMatrixControlAlMaxDesiredEntries.$index 1000]
>     lappend vbl [list hlMatrixControlOwner.$index "policy manager"]
>     lappend vbl [list hlMatrixControlStatus.$index 1]
>     $s set $vbl
> }

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

I'm definitely interested in continuing to work on the API/language to make
scripts shorter and easier to write.

> 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.)

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

> Steve> Here's the complete example. The new code is lines 4-9 and 18:
> [...]
> The fix is flawed as well since the oid in the scratchpad does not say
> which SNMP agent the action is executed on.

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

> 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??

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