Changes between Version 10 and Version 11 of SubnetCommandsDesign


Ignore:
Timestamp:
Sep 14, 2017, 11:01:24 AM (2 months ago)
Author:
tomek
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SubnetCommandsDesign

    v10 v11  
    6262
    6363== Partial updates to subnet configuration ==
    64 In Kea 1.3 release we're planning to implement 4 new types of commands pertaining to (non-shared) subnets:
    65 - subnets listing
    66 - getting a single subnet
    67 - adding a subnet
    68 - removing a subnet
     64In Kea 1.3 release the following commands pertaining to (non-shared) subnets were implemented:
     65- subnets listing: '''subnet4-list''', '''subnet6-list'''
     66- getting a single subnet: '''subnet4-get''', '''subnet6-get'''
     67- adding a subnet: '''subnet4-add''', '''subnet6-add'''
     68- removing a subnet: '''subnet4-del''', '''subnet6-del'''
    6969
    70 The first two commands are simple to implement because they don't modify existing configuration. The next two commands modify the list of subnets. When the new subnet is to be added the subnet parser would have to make sanity check whether this subnet has no conflict with the current configuration. As an example, the parser should check whether a network interface with which the subnet is associated exists and the server is listening on this interface. It should also check whether the options specified for this subnet are correct in terms option definitions used etc. This is currently checked by the parsers so there isn't really a lot of extra work to have such sanity checks.
     70Details regarding those commands can be found here: https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#subnet-cmds
    7171
    72 The parsers will also have to verify that there is no conflict between the new subnet and existing subnets, e.g. duplicate subnet id. More importantly, since we are also implementing support for '''shared subnets''' we have to be careful to check what are the dependencies between the new subnet and other subnets belonging to the same network. When the subnet is being added it is merely needed to update the data structure which holds the information about grouping of subnets into shared subnets. When deleting the subnet, we have to check which shared subnets this subnet belongs to and update that information accordingly.
     72The first four commands are simple to implement because they don't modify existing configuration. The last four commands modify the list of subnets. When the new subnet is to be added the subnet parser conducts sanity check whether this subnet has no conflict with the current configuration. As an example, the parser should check whether a network interface with which the subnet is associated exists and the server is listening on this interface. It should also check whether the options specified for this subnet are correct in terms option definitions used etc.
     73
     74The parsers will also verifies that there is no conflict between the new subnet and existing subnets, e.g. duplicate subnet id. More importantly, since we are also implementing support for '''shared subnets''' we have to be careful to check what are the dependencies between the new subnet and other subnets belonging to the same network. When the subnet is being added it is merely needed to update the data structure which holds the information about grouping of subnets into shared subnets. When deleting the subnet, we have to check which shared subnets this subnet belongs to and update that information accordingly.
    7375
    7476Since the operation of deleting a subnet may trigger updates in several places of the configuration data structure it is important to guarantee atomicity of the configuration update from the server standpoint. This is currently guaranteed by the design of the server which is mono threaded and doesn't run DHCP service while the commands are processed. If in the future the server takes benefit of multi threading, appropriate locking mechanisms will have to be implemented in the Configuration Manager to prevent the server from using a configuration being modified at the same time.
     77
     78== Shared networks support ==
     79
     80Commands for manipulating shared networks are currently out of scope. The primary reason are time constraints. Capability to modify shared networks will be developed in the near future.
    7581
    7682== Actions triggered on subnet deletion ==