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

 * owner:  vorner => zzchen_pku


Comment:

 Hello

 Replying to [comment:9 zzchen_pku]:
 > Replying to [comment:8 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?

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

 Thank you

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