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

Re: snmpconf PM MIB Issue #9





Jon Saperia wrote:
> 
> >
> >
> > Juergen Schoenwaelder wrote:
> > >
> > > >>>>> Steve Waldbusser writes:
> > >
> > > Steve> I believe Juergen's proposal gives the flexibility that the
> > > Steve> write can be done early but it must be complete by the time the
> > > Steve> button push is complete in the snmpStorage MIB. In other words,
> > > Steve> it's like syncing a file system. Prior to the sync the
> > > Steve> application knows that things *might* have been written to disk
> > > Steve> but there is no guarantee. The sync can't complete until any
> > > Steve> unwritten data is written. After the sync the app has a
> > > Steve> guarantee that the data is written.
> > >
> > > Very good summary. Perhaps we should really use the term sync to make
> > > things easier to understand.
> > >
> > > Steve> This adapts to multiple strategies, including: 1) Write to
> > > Steve> nvram immediately on activating the target row (sync is a
> > > Steve> no-op) 2) Every N seconds, look for unwritten rows and write
> > > Steve> them (sync only writes rows that have been modified since last
> > > Steve> interval) 3) Delay writes until sync button is pushed
> > >
> > > Option 3) is a bit problematic with the current StorageType. Right
> > > now, applications assume that setting the StorageType to nonVolatile
> > > is enough to put the configuration information into stable storage,
> > > even though it is right now implementation specific when this actually
> > > happens. But it should happen at some point in time. So only relying
> > > on the sync button might confuse existing applications that do not
> > > know about sync buttons. So if 3) is an option we want, then we
> > > probably need to have a new StorageType kind of TC.
> >
> > Good point.
> >
> > BTW, I'm not pushing for #3 and I've never heard that anyone needed it,
> > so it is not a requirement.
> >
> >
> 
> I am pushing it as a requirement. It is how the operators control their
> network.

I really meant as a required semantic for storageType. I don't know that
we can stretch storageType this far and I've never seen anyone ask us to
stretch it that far (never asked either). Mostly I didn't want to make
it seem like *I* was making it a requirement.

I agree that "write config" is how operators control their network, or
rather: that's the tool that router vendors provide for their customers
to control their network.

> That said, I am not pushing it for the PM module, just for the infrastructure
> work that Juergen is doing.


Steve