BIND 10 #3097: Investigate parser rollback behaviour for DHCP

[BIND 10 Development]

#3097: Investigate parser rollback behaviour for DHCP
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  stephen                            |                Status:  new
                       Type:         |             Milestone:  DHCP
  defect                             |  Outstanding Tasks
                   Priority:  low    |              Keywords:
                  Component:  dhcp   |             Sensitive:  0
               CVSS Scoring:         |           Sub-Project:  DHCP
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
 When parsing a DHCP configuration, each element is parsed by a separate
 parser.  After checking, the changes indicated by the configuration are
 committed. The commit operations are sequential and, if one fails, the
 system should roll back to the pre-configuration-change state.

 For most elements in the configuration this is trivial; the original data
 is stored, changes applied to the active version of the data and, if there
 is a problem, the active data is replaced by the copy. However, two
 elements of the DHCP configuration - the database configuration and the
 hooks libraries configuration - do not follow this model.  In the former,
 committing the change means closing the connection to the existing
 database and opening a connection to the new one.  In the latter, the
 commit means unloading the old hooks libraries and loading the new ones.
 For both cases, rollback cannot be achieved by merely retrieving a stored
 copy of the data; the operation (open database, load libraries) has to be
 performed again.

 The current situation is that the committal of the hooks libraries change
 is the last item done.  However if it fails and the configuration change
 included a change to the database information, the database change will
 not be rolled back; ideally it should.

 This ticket is for the investigation of the problem and the recommendation
 of a solution.

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