BIND 10 #1491: Boss/components config option got set to empty

BIND 10 Development do-not-reply at isc.org
Wed Apr 11 09:11:11 UTC 2012


#1491: Boss/components config option got set to empty
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  UnAssigned
                       Type:         |                Status:  reviewing
  defect                             |             Milestone:
                   Priority:         |  Sprint-20120417
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6
            Defect Severity:         |           Total Hours:  0
  Medium                             |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => UnAssigned


Comment:

 So what happens is, bindctl keeps 'local' data, which is really just the
 changes from the 'current' data as present in cfgmgr. For most basic
 types, changing a value just means giving it a value in local data, and
 when it is committed it is overwritten (after validation etc.). But we
 don't really have a representation of 'changes'; so for lists and sets, if
 we add or remove an element, we need to copy the entire list or set to
 'local data', then remove or add the element (since we have no
 representation of difference, the entire list or set will be overwritten
 when it is committed).

 This was already implemented, but we missed at least one scenario; if a
 child element of a named set is modified, the local data only stores that
 specific element of the set (it is copied if you add or remove an element
 in a named_set directly).

 You can reproduce the problem like this; (warning; this will result in all
 modules being removed, including b10-cmdctl)

 Doing config show Boss/components between each step may show more info on
 what happens; the error after the first commit is unrelated (but
 boss/components is our only use of named_set afaik)

 {{{
 bindctl
 > config set Boss/components/b10-stats kind needed
 > config commit
 Error: Changing configuration of a running component is not yet supported.
 Remove and re-add b10-stats to get the same effect
 Configuration not committed
 > config remove Boss/components b10-stats
 > config commit
 > config show Boss
 Failed to send request, the connection is closed
 }}}

 (then retry this in the branch)

 So when the first set is done, the 'new named set' contains only
 b10-stats, as it is not directly changed itself, and is not copied to
 'local'. Of course in this specific example the commit fails, and you do
 'config remove' on b10-stats, to re-add it later. But after the remove the
 set is empty. If you commit it then, boss will stop all configurable
 modules...

 The immediate solution is to copy named_sets to local data completely if
 any part of it is changed. The real solution is in the api; we need to
 have a way to communicate 'differences' for specific types (additions and
 deletions, for lists and maps, and 'something has changed in a child, but
 leave the rest alone', etc.). I have no doubt that there are more issues
 like this (but this one is the most dangerous one I know of and wanted
 fixed right now, as you can lock yourself out of the system by accident)

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


More information about the bind10-tickets mailing list