[AGENT++] Proposal: Explicit save of persistent objects via SNMP

[Marek Malowidzki]

Sorry, I was in a hurry a bit writing the previos e-mail. While some ideas
still are I believe valid, I would re-state my position.

Looks like you are talking about "Cisco-style" config save on demand. I was
writing more on table serialization.

> > First I thought, it could be a valuable
> > feature to be able to specify which parts of the agent's MIB to store
> > where. But the more I think about it, the more I doubt that this
> > is really useful. What do you think?

Ok, sorry, what I really meant was "which parts of a MIB to store". Of
course, I believe there should be a single configuration - the old (working,
tested one) and a new one.

> You are probably right to doubt that. When I think about it, in everyday
> life I would probably always save all persistent objects and not bother to
> think "Well, which part did I change that needs saving now?". Consider
> router configurations. I always do a "copy run start" on my Ciscos and
never
> wonder which part I want to save, even if IOS provided that feature (does
> it?).
> It was just me playing with this in my  mind but it is not a feature I
would
> need.
>
> For debugging purposes it would be cool, though, to be able to save
multiple
> copies of the configuration. A simple backup feature might do the job:
> Always copy the old configuration to a fixed backup location before saving
> the new one. Then the user could choose to restore the old version if the
> new version does not work. This mechanism would replace my proposed
writable
> object for the configuration directory.
>
> > Another option would be to schedule configuration storage. Probably,
> > storing the configuration each hour or each night could be useful,
> > couldn't it?
> No, I do not see why. The only time I need to save the configuration is
when
> I changed it. This would imply that the configuration might be changed
> constantly which I cannot find a sensible situation for. Well, thinking
> about it: there may be such things as "dynamic trap receivers" which
change
> because the admin always starts the NMS on different machines. But does
that
> really happen?

I would support Henning here - for this kind of configuration, there is no
reason to perform it periodically. I believe that the question stems from
fact that sometimes we would like configuration to be immediately updated
(e.g., password change, maybe a new SNMPv3 user added, etc.). Maybe, we
could do it with some internal API.

With respect to format details, I would support it being human readable, if
possible. Also, a callback after configuration has been changed could be
useful.

Marek

PS. I will try to follow your discussion with more care as I think this
would solve many of our current problems. And we could eliminate some
temporary solutions we have developed for this purpose.