How to deprecate an operdata table?

[Dennis McCracken]

Hi,

I have a table of operational data that I want to deprecate.  I can do this and hide the table but I can't remove the call point without getting a compilation error.  If no one registers for the call point you can't do a mib walk without getting an error.

  list fooStatus {

    config false;

     status deprecated;

    tailf:hidden deprecated;

    tailf:sort-order snmp;

    tailf:snmp-oid .20;

    tailf:info "

      This table presents status";

#    tailf:callpoint fooStatusCP {

#        tailf:config false;

#    }

    ....

    }

confdc output:

        /software/src/common/tailf/bin/confdc --prefix foo --emit-mib db64/fooStatus.mib --top fooStatusMIB -f dependencies_fxs -- db64/fooStatusMib.fxs

db64/fooStatusMib.fxs: <mib location data>: operational data without callpoint.

*** Error code 1

How have others solved this?

Thanks in advance...

-Dennis-

[chriss]

Hi Dennis,

Have you tried using an AAA rule to make it inaccessible to all?

- chris

[Dennis McCracken]

Thanks for the reply Chris. Good to see you around.

I haven't tried that yet. Someone here suggested it but that doesn't smell right to me. Really SNMP should ignore it because of the deprecated status but doesn't.

--
You received this message because you are subscribed to the Google Groups "ConfD User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to confd-user-gro...@googlegroups.com.
To post to this group, send email to confd-us...@googlegroups.com.
Visit this group at http://groups.google.com/group/confd-user-group.
For more options, visit https://groups.google.com/d/optout.

[chriss]

Well, to me "deprecated" means accessible but not recommended for use. It's an administrative status not an access control. So perhaps I am not sure what your objective actually is  Do you want the table appear in the MIB but be inaccessible?Or do you want it to not appear in the MIB at all? I so, if the MIB is generated you can remove the annotations which put it there, or hack a sed script to force it to be inaccessible. If the MIB is not generated, you can use MIB annotation to make the table inaccessible in the ..bin file.If none of this makes sense, please describe the flow of how the yang and MIB relate and maybe I can advise.

- chris

On Thursday, June 12, 2014 9:30:38 AM UTC-7, Dennis McCracken wrote:

Thanks for the reply Chris. Good to see you around.

I haven't tried that yet. Someone here suggested it but that doesn't smell right to me. Really SNMP should ignore it because of the deprecated status but doesn't.

[Dennis McCracken]

Maybe I'm thinking about this wrong.  The term 'deprecated' to me meant it should not be displayed.  But your description of 'accessible but not recommended for use' is probably closer to the true definition of the term.  When thinking about it that way I have to agree.  We can't change the mib OUIs and need to keep the numbering as it is so in fact, the tables don't go away.

What I should probably do here is provide a 'null object' call point that simply returns no data.  I can reuse it for any operational data tables that get deprecated in the future.

-Dennis-

--
You received this message because you are subscribed to the Google Groups "ConfD User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to confd-user-gro...@googlegroups.com.
To post to this group, send email to confd-us...@googlegroups.com.
Visit this group at http://groups.google.com/group/confd-user-group.
For more options, visit https://groups.google.com/d/optout.

--
-Dennis-

[Per Hedeland]

Hi,

Dennis McCracken <dmccra...@gmail.com> wrote:
>
>What I should probably do here is provide a 'null object' call point that
>simply returns no data. I can reuse it for any operational data tables
>that get deprecated in the future.

Now that Chris has sorted out what you actually want to achieve:-), let
me add: In current versions of ConfD (since 4.0 actually), you never get
the "operational data without callpoint" error - since such data now
defaults to being served by CDB, just as has been the case for config
data since pretty much day one.

Thus you don't need to use a callpoint or write dummy data provider code
for a case like this, CDB-operational will be queried and happily reply
"there's nothing here, just move on...". And in pre-4.0 versions, you
can achieve the same effect by manually doing what is now done
automatically - just stick a tailf:cdb-oper in there. Requires that you
actually have CDB-operational enabled of course, but I believe that you
already have that.

Regards

--Per Hedeland