... | ... | @@ -88,7 +88,7 @@ Here's an outline of a functional test: |
|
|
* First is to use a command similar to
|
|
|
```sysrepocfg --import=myconfig.xml --datastore=startup kea-dhcp4-server`` to load the configuration directly into Sysrepo storage. It's useful to explore sysrepocfg options. It supports several formats (at least xml and json and possibly others, xml is recommended to avoid confusion between Kea and YANG configurations). Some of them may be easier to use than others. Note it doesn't make much sense to test all of them, because that would be testing sysrepo functionality.
|
|
|
|
|
|
* Another way to load the configuration is using NETCONF client. A running sysrepod is supposed to expose port 830 and listen for incoming NETCONF connections. This is how most users will most likely be using the software. NETCONF is a standard protocol and there should be various clients available for it. Also, this approach has the benefit (or a flaw, if you happen to be QA) that it can be used remotely. This means that factors such as authentication, open ports, remote attacks and similar may play a factor here. Given the time constraints, it seems sysrepocfg approach is easier. Ultimately, we'll have to test both approaches, though.
|
|
|
* Another way to load the configuration is using NETCONF client. A running sysrepod is supposed to expose port 830 and listen for incoming NETCONF connections. This is how most users will most likely be using the software. NETCONF is a standard protocol and there should be various clients available for it. Also, this approach has the benefit (or a flaw, if you happen to be QA) that it can be used remotely. This means that factors such as authentication, open ports, remote attacks and similar may play a factor here. Given the time constraints, it seems sysrepocfg approach is easier. Ultimately, we'll have to test both approaches, though.
|
|
|
|
|
|
1. Start kea-dhcp4 with a minimal configuration that has only unix socket in it. This is explained in the [Kea user's guide](https://kea.readthedocs.io/en/latest/arm/netconf.html#configuration).
|
|
|
|
... | ... | @@ -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.)
|
|
|
|
... | ... | |