Re: user-array: row deletion and RowStatus

Wes> By your definition, you should have no issues if Wes> I used the TruthValue TC and in the text clause reversed the meaning Wes> of the true/false values (extreme example, of course) I don't think that's a fair comparison. You're talking about changing the semantics of the TC

Re: user-array: row deletion and RowStatus

> On Wed, 24 Nov 2004 13:09:58 -0500, Robert Story (Coders) <[EMAIL > PROTECTED]> said: Robert> On Wed, 24 Nov 2004 09:19:57 -0800 Wes wrote: WH> Dave> I would hope that such managers wouldn't misinterpret this WH> Dave> definition as saying that this *must* be 5 minutes. Robert> Definit

Re: user-array: row deletion and RowStatus

> On Wed, 24 Nov 2004 10:42:05 -0800 (PST), "David T. Perkins" <[EMAIL > PROTECTED]> said: David> Well, this discussion points out the problems with the David> RowStatus model, and is a demonstration why many MIB David> definitions and agent designs support ONLY values David> createAndGo(

Re: user-array: row deletion and RowStatus

On Wed, 24 Nov 2004 08:55:26 -0800 Wes wrote: WH> Robert> notReady is only used during row creation Note that I'm playing the devil's advocate here... the array-user code will work as you described, and I think it probably should work that way, but I've recently come to believe that the TC doesn't

Re: user-array: row deletion and RowStatus

HI, Well, this discussion points out the problems with the RowStatus model, and is a demonstration why many MIB definitions and agent designs support ONLY values createAndGo(4), active(1), and destroy(6). To support other values requires that the resource manager or most probably the agent to kee

Re: user-array: row deletion and RowStatus

On Wed, 24 Nov 2004 09:19:57 -0800 Wes wrote: WH> Dave> I would hope that such managers wouldn't misinterpret this WH> Dave> definition as saying that this *must* be 5 minutes. Definitely agree w/Dave here... -- Robert Story; NET-SNMP Junkie Support: Archive:

Re: user-array: row deletion and RowStatus

> On Wed, 24 Nov 2004 16:58:25 +, Dave Shield <[EMAIL PROTECTED]> said: >> The only issue would then be a manager that expects a certain >> behavior of the TC (which is what it has to go on). Dave> Including parsing the free text of the MIB description, I trust. No. Dave> I would hope t

Re: user-array: row deletion and RowStatus

> On Wed, 24 Nov 2004 15:32:31 +, Dave Shield <[EMAIL PROTECTED]> said: Robert> notReady is only used during row creation Dave> Where does it say that? My guess is that Dave is right, but it should rarely happen. You could put a row into notInService and then it could transition from th

Re: user-array: row deletion and RowStatus

Dave> I suggest you take a closer look at the DESCRIPTION field of Dave> such MIB objects as NET-SNMP-AGENT-MIB::nsDebugTokenStatus, Dave> nsLogStatus and NET-SNMP-EXTEND-MIB::nsExtendStatus Wes> Ahh... getting around TC definitions by changing it post-call. Chamging it? I'm just following the

Re: user-array: row deletion and RowStatus

> On Wed, 24 Nov 2004 15:55:02 +, Dave Shield <[EMAIL PROTECTED]> said: Dave> I suggest you take a closer look at the DESCRIPTION field of such Dave> MIB objects as NET-SNMP-AGENT-MIB::nsDebugTokenStatus, nsLogStatus Dave> and NET-SNMP-EXTEND-MIB::nsExtendStatus One last point: The IETF

Re: user-array: row deletion and RowStatus

> On Wed, 24 Nov 2004 15:55:02 +, Dave Shield <[EMAIL PROTECTED]> said: Dave> I suggest you take a closer look at the DESCRIPTION field of Dave> such MIB objects as NET-SNMP-AGENT-MIB::nsDebugTokenStatus, Dave> nsLogStatus and NET-SNMP-EXTEND-MIB::nsExtendStatus Ahh... getting around TC

Re: user-array: row deletion and RowStatus

Dave> Then a fuse blows, and all the toasters are knocked out. Dave> Fortunately the SNMP device is powered via a UPS, so can Dave> report the fact ('notReady'). Wes> FYI, the notReady state is not supposed to be used for not active Wes> conditions. Specifically, the rowstatus TC actually says th

Re: user-array: row deletion and RowStatus

Dave> Hmmm... I see what you mean, but I don't think it's as simple as that. Dave> The RowStatus TC feels to be somewhat ambiguous (if not inconsistent). Robert> Yep, I notices the sufficient wording too. I've been hoping that Robert> Mr. Perkins would jump in here with his 2 cents.. Yes - tha

Re: user-array: row deletion and RowStatus

> On Wed, 24 Nov 2004 10:45:03 +, Dave Shield <[EMAIL PROTECTED]> said: Dave> Then a fuse blows, and all the toasters are knocked out. Fortunately Dave> the SNMP device is powered via a UPS, so can report the fact Dave> ('notReady'). FYI, the notReady state is not supposed to be used for

Re: user-array: row deletion and RowStatus

On Wed, 24 Nov 2004 10:45:03 + Dave wrote: DS> Dave> I can envisage situations where a table might well be missing two DS> Dave> or three "minor" column values, but still be ready to go live. DS> Robert> I think that the RowStatus TC doesn't allow that. DS> DS> Hmmm... I see what you mean, bu

Re: user-array: row deletion and RowStatus

Dave> I can envisage situations where a table might well be missing two Dave> or three "minor" column values, but still be ready to go live. Robert> I think that the RowStatus TC doesn't allow that. Hmmm... I see what you mean, but I don't think it's as simple as that. The RowStatus TC feels to

Re: user-array: row deletion and RowStatus

On Tue, 23 Nov 2004 15:14:20 + Dave wrote: DS> > It wouldn't be too hard to add a flag which could be set during DS> > registration, and would signal the helper to not create the row. DS> DS> It wouldn't even have to change the API. DS> DS> The final parameter to 'netsnmp_table_container_regi

Re: user-array: row deletion and RowStatus

> It wouldn't be too hard to add a flag which could be set during > registration, and would signal the helper to not create the row. It wouldn't even have to change the API. The final parameter to 'netsnmp_table_container_register' is currently a boolean flag to control whether rows should be gr

Re: user-array: row deletion and RowStatus

On Tue, 23 Nov 2004 14:01:34 + Dave wrote: DS> > The idea was that the user module shouldn't have to worry about DS> > creating/deleting rows. DS> DS> It's perfectly reasonable that the user module shouldn't *have* to worry DS> about creating rows. I'm less happy that they're effectively not

Re: user-array: row deletion and RowStatus

> The generated code could be tweaked to detect completely invalid RowStatus > creation attempts (eg no RowStatus varbind in the request) in reserve1 > fairly easily Hmmm... I suppose so. It feels a bit clunky, but should work. Things would get much more cumbersome if the "row grouping" was tur

Re: user-array: row deletion and RowStatus

On Sun, 21 Nov 2004 22:06:56 + Dave wrote: DS> DS>The 'create_row' hook DS> DS> seems to activate the automatic creation of rows ... But this DS> DS> isn't what's needed for a pure RowStatus-controlled table. DS> DS> RS> Hmm... ok, what is needed? DS> D

Re: user-array: row deletion and RowStatus

RS> The array-user helper is pretty insistent about doing the insertion RS> (other than at startup) and deletion for you. OK - that's useful to know. Thanks. DS> What's the approved way for removing a row using this helper? RS> If you look at the helper code, during a commit it checks the R

Re: user-array: row deletion and RowStatus

On Fri, 19 Nov 2004 13:46:03 + Dave wrote: DS> The first is how to delete a particular row from a table. DS> The 'delete_row' hook routine seems to be concerned with releasing DS> the per-row data structure, rather than removing it from the table DS> container. There seems to be some code w