BIND 10 #1153: zonemgr exits on empty zones

[BIND 10 Development]

#1153: zonemgr exits on empty zones
-------------------------------------+-------------------------------------
                   Reporter:  shane  |                 Owner:  zzchen_pku
                       Type:         |                Status:  reviewing
  defect                             |             Milestone:
                   Priority:  major  |  Sprint-20110830
                  Component:         |            Resolution:
  secondary manager                  |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:         |  Estimated Difficulty:  0
  Medium                             |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by zzchen_pku):

 Replying to [comment:10 vorner]:
 > > > However, I have some questions, more from the design/UI point, than
 from code point:
 > > >  * This way, when I try to add a non-existent zone to the
 configuration, it will let me, right (not tested, just guessing from
 reading the code)? If it is true, maybe this isn't the best idea, user
 should be notified of typos and stuff right away, in the program where he
 typed the typo. So in that sense, it should be better to tell the user and
 reject the config if it comes from user and accept it when it is the
 first-time config and just skip the zone and log the information (so it is
 both logged and attention brought to it next time someone comes to
 configure something).
 > > The problem is, user may modify the config at run time and add some
 new secondary zones, all of them  are non-existent zones for bind10 back-
 end db(of course, user may configure some bad zone name(such as typo), but
 we don't know about it , we can't decide to reject it or not),  we should
 try to do xfrin for all these zones.
 >
 > Well, that sounds like a really non-intuitive way of doing it. And to
 make it work, a little bit more work should be done, too. Or I probably
 didn't match the Zonemgr and Xfrin configs:
 > {{{
 > 2011-08-23 18:57:08.488 WARN  [b10-zonemgr.zonemgr] ZONEMGR_NO_SOA zone
 example.org. (class IN) does not have an SOA record
 > 2011-08-23 18:57:10.497 ERROR [b10-xfrin.xfrin]
 XFRIN_RETRANSFER_UNKNOWN_ZONE got notification to retransfer unknown zone
 example.org.
 > }}}
 >
 > Personally, I'd like something like (with the log-output very
 simplified):
 > {{{
 > > Zonemgr add_secondary exampel.org IN 192.0.2.1 53
 > Log: INFO Setting up a new zone
 > Log: INFO Contacting master and downloading content of the new zone
 > Log: WARN Master does not know the zone
 > Error: The remote master does not know the zone
 > }}}
 >
 > The command would first try to get the data and then update all relevant
 configs.
 >
 > Or maybe having a single place where zones are configured would satisfy
 me O:-).
 >
 > But I'll not block the ticket about this, the rationale behind your
 point of view is valid, even when I believe the interface as
 uncomfortable. So, would you mind bringing this up at the list to discuss
 it?
 Sure.
 > > >  * Provided the first point is fixed and it is not possible to add a
 non-existent zone into the config in any „conventional“ way (except by
 manually transfering or editing the config file or messing with the DB),
 the level might better be ERROR than WARN, because in that case it should
 not happen in usual condition and the state indicates something is wrong
 for sure (it is OK not to terminate with ERROR, the one for termination-
 causing errors is FATAL).
 > > The same as the first point, because it may happen in usual
 condition(new zone was configured as secondary the first time or at
 runtime ), log level WARN should be enough.
 >
 > Yes, in that case WARN is probably enough. Depends on if we want to
 allow adding zones this way or it is better trough a dedicated command.
 >
 > So, the ticket can be merged. Could you post to the list, for followup
 discussion about the interface?
 Okay, thanks for your review.

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