BIND 10 #916: implement a prototype for stats snmp interface

[BIND 10 Development]

#916: implement a prototype for stats snmp interface
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  vorner
  naokikambe                         |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111220
                  Component:         |            Resolution:
  statistics                         |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  10
Feature Depending on Ticket:  SNMP   |           Total Hours:  0
  stats                              |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by naokikambe):

 * owner:  naokikambe => vorner


Comment:

 Replying to [comment:10 vorner]:
 Sorry for my late response.

 > As this is only prototype code, I didn't take a close look to stuff like
 programming and style practices and mostly ignored the tests in the review
 as well.

 Thank you! That's no problem. The result of this task is just an
 assistance
 for the next documentation #1448.

 > I've noticed some slight things, that may be just because this is simple
 experimental version:
 >  * It seems the list of items (or whatever it is called) is generated
 from spec files manually rather than dynamically on the fly. As the
 daemons might come and go and nothing really makes them say where their
 spec file is (provided it is in a file at all), this doesn't seem correct.

 Do you mention about {{{gen-mibfile.py}}}? That is loaded only when
 bind10 is compiled. Anyway in such circumstances as the SNMP feature
 is used, we don't imagine that the list of statistics items can be
 changed unexpectedly by the user hands, whenever bind10 codes are
 being complied or the bind10 daemons are running. However, this might
 be incorrect but I cannot imagine the better way. Because SNMP doesn't
 provide the way to change the list dynamically.

 >  * When a request is made, it downloads the whole set of statistics over
 message bus and then picks the single one it needed. Shouldn't it ak only
 for the needed data?

 It isn't OK. That is a bug on the prototype. I will fix it in the
 implementation phase. I've added the TODO tag at git f96e8b7. Could
 you see that?

 >  * While the http stats daemon servers its own http daemon, this one
 seems to be used from inside some other external tool. It is slightly
 inconsistent, but I don't think it should pose some other kind of problem.

 That's good point. In order to keep consistency with the HTTP stats
 daemon, I think such SNMP daemon should be independent too. But SNMP
 is technically so complicated that the implementation including the
 deamonlization cannot be completed within the Y3 plan. Otherwise a
 library for SNMP like http.server might be useful if there is. OTOH,
 most of the system administrators may want the bind10 daemon to
 coexist with the SNMP daemon like net-snmp for monitoring
 availabilities of the whole system. Then the situation might be more
 complicated.  That's the reason why I choose the pass_persis directive
 in snmpd.conf for the convenience. I think the new trial to daemonlize
 should be put in the scope of Y4 or later.

 > Or, was this the purpose of the review? I'm not sure, if you don't want
 to merge to master, it feels slightly unusual.

 Sorry for the confusion. I don't think that branch should be merged
 with the master. But the codes in the branch are very useful for the
 implementation phase which will come after the documentation phase
 #1448, I won't delete that branch.

 Thanks,

-- 
Ticket URL: <http://bind10.isc.org/ticket/916#comment:11>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development