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

[BIND 10 Development]

#916: implement a prototype for stats snmp interface
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  naokikambe
  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.75
  stats                              |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => naokikambe
 * totalhours:  0 => 0.75


Comment:

 Hello

 Replying to [comment:11 naokikambe]:
 > > 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.

 Yes, mostly because the gen-mibfile.py and generally the thing that
 because it looks like the list of statistics is considered static in more
 or less dynamic bind10, which feels strange.

 I guess SNMP doesn't support a way to push the change of list actively.
 But it must be able to answer a query „give me list of variables“ and the
 answer could be different for future queries.

 What I fear is, user will start up for the first time, it will create some
 statistic list for him, then disables auth and enables resolver. Provided
 the first list was correct, it now must be wrong. So it would make sense
 to me to delay the creation of the list for the time the list of variables
 is requested.

 But that might be just my preference. Maybe the problem I see wouldn't be
 issue in real life anyway.

 > >  * 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.

 I see.

 > > 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.

 So, then, you probably can close this ticket whenever you feel like it, I
 guess, and keep the branch around. Maybe the branch could be renamed to
 some experiments/something so it is not deleted on some cleanup?

 With regards

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