Changes between Version 8 and Version 9 of ConfigParseDesign


Ignore:
Timestamp:
Nov 25, 2016, 6:54:13 PM (12 months ago)
Author:
tomek
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ConfigParseDesign

    v8 v9  
    99== Issues with Current Configuration Parsers ==
    1010
    11 === Unused spec Files ===
     11=== 1. Unused spec Files ===
    1212
    1313Spec files were introduced in BIND10 to define the structures of the configuration information used for different modules. The RESTful API exposed parameters defined in the spec files to the client application, called bindctl, which was used to modify the parameters. Since, bindctl didn't expose parameters which didn't exist in the spec files, there was no need for the parsers to validate whether the configuration structure adhered to the spec files. When the BIND10 framework was removed, Kea deamons have become standalone applications using JSON files as the configuration storage. Every deamon is now fully responsible for reading the configuration from the file and validating that the data types and the hierarchy of the parameters are correct. The legacy parsers have no support for validating the configuration against the spec file. As a result, some configuration parsers implement sanity checks for unsupported or invalid parameters but this requires modification of the configuration parser for each new parameter. Also, hardcoding the supported parameters makes it troublesome to keep the configuration documentation up to date and provides no means for the user to view the configuration options.
     
    1717- The spec file should be used to validate that the hierarchy of the parameters and their types is correct
    1818
    19 === Parsing Order Does Matter ===
     19=== 2. Parsing Order Does Matter ===
    2020
    2121Some of the configuration parameters exposed by Kea are interdependent. For example, Kea allows for defining custom option formats, a.k.a. option definitions. The definition includes the option code, type of values conveyed in the option fields etc. This definition doesn't include the actual data to be sent in the option. The option data is specified elsewhere in the configuration file. The option-data parser must verify if the data specified by the user adheres to the option format before accepting the data. This implies that the option definition must be known upfront and therefore the option definition must be parsed before the option data. Currently, the order in which the parsers are invoked is hardcoded and the code launching the configuration parsers is quite convoluted.
     
    2424- The order in which the configuration parsers are executed should not be harcoded but rather defined in the spec file
    2525
    26 === Abuse of !''commit!'' ===
     26=== 3. Abuse of !''commit!'' ===
    2727
    2828All configuration parsers derive from the common base class and implement two functions: ''build'' and ''commit''. The build is meant to read the configuration information from the JSON data structures, validate it and store in the temporary storage. The ''commit'' was invoked for all parsers to move the configuration from the temporary storage to the Configuration Manager which holds the whole server configuration. However, due to interdependencies between various configuration parameters it was necessary to execute ''commit'' on some parsers so as the other parsers have access to the committed information. This violates the original concept of separation of the ''build'' and ''commit'' phases, according to which the !''commit!'' should not trigger exceptions.
     
    3232- The ''commit'' should not be executed by the configuration parsers but rather by the configuration manager after all configuration parsers are done parsing.
    3333
    34 === No rollback capability ===
     34=== 4. No rollback capability ===
    3535
    3636As described in the previous section, some configuration parsers need to commit changes to provide access to the configuration information to other parsers. This leads to the states of !''partially committed!'' information which disrupts the configuration data integrity. To avoid this problem, the code which triggers the server configuration, stores the currently used configuration information in the local data structures, and if the configuration fails the server is reconfigured with stored data. The Configuration Manager doesn't provide any capability to manage the process of rolling back changes and for each newly defined parameter the !''workaround!'' code has to be updated to guarantee that al changes are rolled back when appropriate.
     
    3838Briefly:
    3939- The configuration mechanism must use the rollback mechanism described [https://lists.isc.org/pipermail/kea-dev/2014-August/000065.html here]
    40 
    4140
    4241== The Design ==