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

Re: snmpconf PM MIB Issue #9

One thing to keep in mind here is that configuration for next generation 
devices can become quite large.  It is quite likely that configuration 
cannot be written prior to SNMP timeout.  If I take the UCD tools as my 
model, the SET request will be sent again, thus causing more work.

I'm not saying that you can't have a "write this now" button, just that you 
need to do something a little bit smarter than a single MIB object.


--On Wednesday, June 20, 2001 10:51 AM +0200 Juergen Schoenwaelder 
<schoenw@ibr.cs.tu-bs.de> wrote:

>>>>>> Wes Hardaker writes:
> Wes> I'm not convinced that forcing this upon the implementer is a
> Wes> "good thing".  It's entirely possible that some implementations
> Wes> will only be able to write immediately, and others will not be
> Wes> able to write until some time X later.
> Which means that management applications can never know whether a
> configuration change has been committed to stable storage. From a
> management application perspective, this is unworkable. (And all the
> CLIs I have seen sofar have a "write config now" button. So why is
> that too hard to put into an SNMP agent?)
> Wes> I fail to see what the problem is with the existing storage type
> Wes> mechanisms.  If one box must write everything nonVolatile at once
> Wes> and another one may not, then it is sort of implementation
> Wes> specific as to what saving methodology is used.
> The problem is that management applications have no clue when a
> configuration change is reflected in stable storage and hence they
> can't seriously make any assumptions that a row which is "nonVolatile"
> is still there after a device reboot/crash. I know one implementation
> which writes to stable storage when the agent exits (which won't work
> if the agent or the system crashes). I know other implementations
> which delay writes to speed up the processing of SNMP set
> operations. Again, there is a time window where changes to
> "nonVolatile" rows might get lost.
> The proposal adds explicit write buttons so when a management
> application touches the button, it will be sure that the configuration
> in stable storage is updated. This does not reduce your freedom to not
> implement such a write button and to continue with the old behaviour
> where things are written to stable storage whenever the implementor
> things it is a good time to do so.
> In fact, the write buttons would be an _additional_ explicit mechanism
> to help management applications that want to know when configuration
> changes are saved in stable storage.
> /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/>