... | ... | @@ -90,7 +90,7 @@ Here's an outline of a functional test: |
|
|
|
|
|
* 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, section 20.6](https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#kea-netconf).
|
|
|
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).
|
|
|
|
|
|
1. 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.
|
|
|
|
... | ... | |