[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf General Functional Questions
on 06/29/2000 9:33 AM, Joel M. Halpern at email@example.com wrote:
> There are at least two problems that I see being aluded to here. Both are
> related to the phrase "if a variable is unde3r control of more than one
> policy". We do need to make sure we understand what we want to happen in
> that case.
> 1) If you set that variable with SNMP, assuming that the intention is to
> override the policy setting of that variable, then I believe that you are
> overriding ALL the policies which set that variable. Trying to achieve
> some intermediate state where some of the policies apply to that variable,
> but not all of them, would be better done by actually changing the set of
> roles, rather than trying to force-off. force-off is for the case when the
> manual intervention is moving the variable out of the policy space
Joel, sorry for the late reply. This is still quite relevant to the
discussion Steve and I have been having on the list related to this topic.
With this definition of force-off we could perhaps get rid of my suggested
modified. I think we are looking for two separate things here which is why
two enumerated values might be helpful:
1. Turn this off for a while (the forced off state). One of the problems
I think we want to address is to make it easier for operators to take things
in an out of policy (while reducing the drive to entropy that Steve is
concerned with) without the more heavy weight role redefintions. Role
changes and new policy creation is more work for the humans and computers,
especially when one considers that for this function the human intends the
element to return to the policy in the reasonable future.
2. This is a variant of point 1 except that a human wants for
fire-fighting reasons - or something akin to that- to change a value of an
element under policy control (modified).
I have to agree with you when you say that if an element has an object that
is set by many policies (would of course have to be the same value), then
all policies should be considered to have been overridden for the purposes
of this element. I believe the tables allow for this level of expression.
> 2) In practice the variable can not really be set by more than one
> policy. There is some sort of conflict which has essentially been resolved
> by "last touch wins". Unless we are forcing order of evaluation of policy
> (and what about order of re-evaluation?) such a conflict resolution
> mechanism is exceedingly risky. This goes on the conflict resolution thread.
Agreed. I do think policy group and a unique policy priority per managed
system will help.
> Related to this, I believe that the intention of most of the discussants is
> that if a human being directly modifies a variable whose current state was
> effected by policy, then that variable better be removed from policy
> control automatically. Otherwise, the user will get unexpected effects
> wherein his changes evaporate periodically (or even worse, some of them
> evaporate, but not all).
I think this is about right. I would modify it a bit and say, removed from
the perspective of control, not membership. The point is that there is an
expectation in this case that in the not distant future, the element will
once again be returned by the human that changed the value to the warm and
peaceful and controlling embrace of the policy:-)