BIND 10 #1153: zonemgr exits on empty zones

[BIND 10 Development]

#1153: zonemgr exits on empty zones
-------------------------------------+-------------------------------------
                   Reporter:  shane  |                 Owner:  vorner
                       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 zzchen_pku):

 * owner:  zzchen_pku => vorner


Comment:

 Replying to [comment:8 vorner]:
 > Hello
 >
 > I pushed small editorial fix.
 Thanks.
 > 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.
 >  * If there's a zone missing from database, it is currently considered
 to be up-to-date:
 > {{{#!python
 > -if (self._zone_is_expired(zone_name_class)):
 > +if ((self._get_zone_soa_rdata(zone_name_class) is not None) and
 > +     self._zone_is_expired(zone_name_class)):
 >      self._set_zone_state(zone_name_class, ZONE_EXPIRED)
 >  else:
 >      self._set_zone_state(zone_name_class, ZONE_OK)
 > }}}
 >    I believe it might be better to consider such missing/empty zone as
 expired instead, which might (if the user is lucky) just fix itself by
 transfering/downloading the zone
 That's fine, updated.
 > (Where do we take the primary master address? Config?).
 Yes, we can take the primary master address from the Xfrin config.
 >  * 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.
 >  * You remove the try-except block with backing up original
 configuration in `ce3be84b9f772fda5f08947fec92764119989019`. Even when you
 remove the exception, there might be other future or unknown exceptions
 and the block still might be useful. Would it be possible to put it back,
 just in case?
 Ok, added.
 > As it is a bugfix, it might use a changelog entry. Would you mind
 providing one, please?
 {{{
 279.    [bug]      jerry
     b10-zonemgr:  zonemgr will not terminate on empty zones,  it will log
 an warning and try to do zone
  transfer for them.
     (Trac #1153, git TBD)
 }}}

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