BIND 10 #2178: Logging for Out-of-zone data

[BIND 10 Development]

#2178: Logging for Out-of-zone data
-------------------------------------+-------------------------------------
                   Reporter:  jreed  |                 Owner:  jinmei
                       Type:         |                Status:  reviewing
  defect                             |             Milestone:
                   Priority:         |  Sprint-20120904
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  3
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:11 jelte]:

 First off, to be clear, I'm okay with merging the branch as its
 current form.

 > > > > Bigger issues:
 > > > > - The current error handling in ConfigurableClientList::configure
 > > > >   seems quite ad hoc and policyless.  [...]
 > > >
 > > > Probably, but I do hope we can get something easier to edit than
 command/config in auth :)
 > >
 > > Hmm, I'm not sure how the auth config implementation is related in
 > > this context.  Out of curiosity, what kind of difficulty are you
 > > seeing?
 >
 > while we have a number of config/command related handlers that are too
 flat and naive, IMO the configparser classes in auth overshot on the other
 side, and it has a bit too much abstraction and code going on for what it
 does, making it less flexible than it could be, and more complicated to
 change than necessary.
 >
 > Perhaps if we filter out the essentials and make a framework out of it
 it would be better (keeping most if not all of the current things it does,
 like the build->commit design), as we would then at least have a standard
 way to do it, but right now it seems a bit overdone and too auth-specific.

 Okay, points taken.  As the person who wrote that stuff first, I admit
 in its current state the complexity of the abstraction may not buy
 much.  But configurable knobs tend to grow rapidly once we reach that
 stage, and I guess we can generally agree that flat-style
 configuration handler (which would normally have hundreds of if-else
 of switch-case blocks) will soon have scalability problems, aside from
 the current style of abstraction is a good way to address the issue.
 I also wanted to make it externally pluggable in future, so someone
 can extend the configuration just by defining a derived class of
 `ConfigParser`, and somehow plug it into the system, preferably
 without requiring rebuild.

 As for auth-specific'ness, I'm not so sure if it's too much so.  The
 concept of build->commit is generic, and the base parser class is in
 fact mostly independent from specifics of auth except for its name:
 `AuthConfigParser`.  I'm not sure if I explicitly documented it, but I
 certainly intended to use it as a general framework some day, not only
 for auth.

 Anyway, whether or not if we use this specific design pattern, I agree
 it's better we have a general framework for config parser/handler.

 > > comment (cited above), "what we should do if remote config update
 > > fails in general", whether or not it's reported in the form of
 > > exception.  Errors can happen (just like we see it in this topic), and
 > > even if we hide the corresponding exception, the problem of how we
 > > ensure the system-level consistency among different modules that
 > > share the config doesn't go away.  That's what I meant by "part of
 > > another big problem".
 >
 > that is one reason i wanted to keep things 'local' as much as possible
 (and why i tend to dislike system-wide settings). Unless whatever checks a
 certain snippet of config verifies it well and completely, this may
 happen, and whoever 'owns' the data is responsible for it, but cannot make
 sure that other 'users' of said data can handle it correctly.

 Maybe I don't understand it well, but I personally don't think it's
 because system-wide settings.  Unless different modules can run
 completely independently, we still encounter a situation where some of
 them share some kind of state/information/config, etc, and ensuring
 consistency will generally be an issue (and it's a difficult one).
 That's the case whether we implement it as a system-wide configuration
 (like the revised "data_sources") or a config in a single module that
 can be referenced by other modules (like "secondary zones" in zonemgr
 referenced by ddns).

 > hmm. monday-morning-wild-idea-time: perhaps config container classes
 should be shared libraries (shared by the modules that use them) as well.

 I'm afraid, in general, module specific errors cannot be completely
 avoided, but providing a unified config handler with unified error
 handling policy will help ensure the consistency in practice.

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