The NETCONF project within Kea is a task to add the ability to store the configuration information in a "SYSREPO" database. This stores data according to a YANG schema definition and interacts with the outside world via NETCONF messages.
Another document (TBD) gives a test plan for an arbitrary configuration backend. The final test suite is expected to incorporate the tests defined there in the test suite for the sysrepo backend. This document concentrates on the NETCONF-specific aspects of the tests.
This document addresses the NETCONF requirements document version a7a47cae.
A visual inspection of the YANG schema should be undertaken.
The reviewer should verify that the YANG schema for DHCPv4 contains entries for:
- IPv4 shared networks (M1.1)
- IPv4 subnets (M1.2)
- IPv4 pools (M1.3)
- IPv4 host reservations within IPv4 subnets (M1.4)
- Client classes with the ability to define V4 options (M1.5) 5.1 Class name 5.2 Expression for evaluation on incoming packet 5.3 List of option values
- Association of IPv4 options on pools (M1.6 - desirable)
- Association of IPv4 options with subnets (M1.7)
- Association of IPv4 options with shared networks (M1.8 - desirable)
Note the unit tests verify example configurations so this was done.
The reviewer should verify that the YANG schema for DHCPv6 contains entries for:
- IPv6 shared networks (M2.1)
- IPv6 subnets (M2.2)
- IPv6 pools (M2.3) 3.1 Addresses 3.2 Prefixes
- IPv6 host reservations within IPv6 subnets (M2.4)
- Client classes with the ability to define V6 options (M2.5) 5.1 Class name 5.2 Expression for evaluation on incoming packet 5.3 List of option values
- Association of IPv6 options on pools (M2.6 - desirable)
- Association of IPv6 options with subnets (M2.7 - desirable)
- Association of IPv6 options with shared networks (M2.8 - desirable)
Note there is no formal check for requirement M2 "A YANG model for DHCPv6 MUST be based on draft-ietf-dhc-dhcpv6-yang". "Based on" is a very loose term and it is felt that this item is more a suggestion than an explicit requirement.
Note the unit tests verify example configurations so it was done for kea-dhcp6-server model.
Requirement N.4 states that the kea-netconf daemon, which is the interface between sysrepo and the rest of Kea - should be able send the Kea commands to standard output. This feature will be used in the tests.
For both IPv4 and IPv6
Create a configuration that includes all of the IPv4/6 elements described above. This will involve using sysrepo tools to add elements to the database.
Start up kea-netconf, which should be configured to route its output to stdout. It should retrieve the initial configuration and send it to stdout as a JSON string (N1, N3, N4).
The string should be inspected and compared with the configuration. (Note: the string may need to be formatted before inspection. When verified, the string can be stored and used for comparison in future tests.)
The configuration should be changed. kea-netconf should output a JSON configuration string that corresponds to the element changed. This should be repeated for a number of different configuration items.
A short program to read from a Unix socket and write to a file should be written to check that the kea-netconf daemon can write to a socket (N5).
Use of "nc" to read from port 80 can check kea-netconf's ability to write to an HTTP connection. (N6)
Inspection of the log output to see that it is similar to the regular Kea log will confirm N8.
Note: Requirement N7 (addition of hooks) is not mentioned here. Tests will be decided once it is known what is being implemented.
NOTE IPv6 NETCONF will not be implemented in kea 1.5.
NOTE In fact it (IPv6 NETCONF) will be implemented at the same time than IPv4 NETCONF.
DHCPv4 Functional Requirements
This section will follow the DHCPv4 tests in the configuration backend test, albeit using sysrepo as the database.
PROPOSAL: Here's an outline of a functional test:
Starts sysrepod, install kea-dhcp4-server model. This is mostly environment preparation. Should be done once, before the tests.
Load YANG configuration. This can be in at least two ways.
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.
Start kea-dhcp4 with a minimal configuration that has only unix socket in it. This is explained in the Kea user's guide.
Start kea-netconf with appropriate configuration. It must at least have the managed-servers entry with dhcp4 in it. It should point to the unix socket that was configured in kea-dhcp4 configuration. Once started, it should retrieve the whole configuration from sysrepo and send config-set over to kea-dhcp4.
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).
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.)
DHCPv6 Functional Requirements
This section will follow the DHCPv6 tests in the configuration backend test, albeit using sysrepo as the database.
NOTE IPv6 NETCONF will not be implemented in kea 1.5.
NOTE In fact it will be supported (more work to do DHCPv4 only than both): the DHCPv4 plan can be applied.
Testing depends on how the "configure" checks are implemented and how sysrepo is installed. Usually a --with-sysrepo[=] flag is provided with the following options:
- Absent - Kea builds without sysrepo.
- --with-sysrepo=yes (or --with-sysrepo) - Kea builds against sysrepo, assuming that it is installed in a default location. This may use a png-config file if one is supplied.
- --with-sysrepo= - Kea builds against sysrepo, with the location being specified.
Tests should be done on both a system with sysrepo installed and one with sysrepo not installed. All that is required is that Kea configures and builds correctly.