... | ... | @@ -96,7 +96,7 @@ Here's an outline of a functional test: |
|
|
|
|
|
There are many aspects to consider here. the kea-netconf can be told to send the commands to stdout rather to unix socket. This has little practical value, but can be super helpful in testing. It will allow us to investigate whether the netconf sent correct or invalid config-set.
|
|
|
|
|
|
Please study boot-update (it determines whether starting kea-netconf should retrieve full configuration at the beginning of its operation), subscribe-changes (this determines whether kea-netconf then subscribes and listens to any changes appearing while kea is running) and validate-changes (this lets kea-netconf to retrieve the changes twice. the first time the results will be sent to kea using config-test. This has a huge potential for catching up configuration errors. It should also be a a very reach area of potential bugs).
|
|
|
Please study boot-update (it determines whether starting kea-netconf should retrieve full configuration at the beginning of its operation), subscribe-changes (this determines whether kea-netconf then subscribes and listens to any changes appearing while kea is running) and validate-changes (this lets kea-netconf to retrieve the changes twice. the first time the results will be sent to kea using config-test. This has a huge potential for catching up configuration errors. It should also be a very reach area of potential bugs).
|
|
|
|
|
|
The simplest tests could start with boot-update = true and subscribe-changes and validate-changes set to false. More complex tests would have subscribe-changes = true. They would require the test environment to change something in the configuration while both kea-netconf and kea-dhcp4 are running. Finally, the most sophisticated tests would run with validate-changes set to true and they would check if kea is able to reject subtly broken configuration (such as overlapping subnets, duplicate subnet-ids, incorrect identifier types, empty required fields etc.)
|
|
|
|
... | ... | |