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      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => jinmei


Comment:

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

 > Regarding the "don't throw" requirement in the remote config handler,
 > while I've not fully thought about it, in my gut feeling it's not
 > about throw or no throw, because it should be possible to catch
 > exceptions in the caller side of the module CC if it were only about
 > exception.  The real issue seems, as I mentioned in the previous

 and it does catch that, but as this ticket shows it may have lost too much
 context to be useful in error reporting :)

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

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

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