mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-08-30 13:37:55 +00:00
Code Issues Releases Wiki Activity

[#5,!53] Updated netconf docs

Browse Source
This commit is contained in:
Tomek Mrugalski
2018-10-17 12:19:17 +02:00
committed by Francis Dupont
parent acd7319085
commit 6c231d5fc9
1 changed files with 27 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
doc/guide/netconf.xml
View File

@@ -292,18 +292,20 @@ ietf-dhcpv6-types | 2018-01-30 | Imported | |
<listitem> <listitem>
<simpara> <simpara>
The <command>validate-changes</command> controls the subscription The <command>validate-changes</command> controls how Kea monitors
option: when true (the default) a module change callback the changes in Sysrepo configuration. Sysrepo offers two stages
is subscribed for both validation and application, when false where Kea could interact: validation and application. The first one
it is subscribed only for application. is called validation (or SR_EV_VERIFY in Sysrepo naming
convention). At this stage Kea will get the new configuration being
<!-- Incorrect change: committed and will verify it. If the configuration is incorrect for
is subscribed for both validation and application. This means whatever reason, Kea servers will reject it, the error will be
that the kea-netconf will call config-test first and then, propagated back to the Sysrepo, which in will return an error to
if it is successful, will call config-set to actually apply whoever tried to commit those changes. This step only takes place if
the configuration. This approach is safer, but slower. validate-changes is set to true. There is also a second step called
When false it is subscribed only for application. application (or SR_EV_APPLY in Sysrepo naming convention), where
--> the actual configuration is being applied. At this stage Kea can
receive the configuration, but it is too late to signal back any
errors, as the configuration has been comitted already.
</simpara> </simpara>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
@@ -333,11 +335,14 @@ ietf-dhcpv6-types | 2018-01-30 | Imported | |
</para> </para>
<para> <para>
With module change subscriptions the <command>sysrepocfg</command> With module change subscriptions enabled, the kea-netconf daemon will
command is used to modify YANG configurations in the running monitor any configuration changes as they appear in the sysrepo. Such
datastore. Note committed configurations are only updated in changes can be done using <command>sysrepocfg</command> tool or remotely
the running datastore: to keep them between server reboots using any NETCONF client. For details, please see Sysrepo
they must be copied to the startup datastore. documentation. Those tools can be used to modify YANG configurations in
the running datastore. Note committed configurations are only updated in
the running datastore: to keep them between server reboots they must be
copied to the startup datastore.
</para> </para>
<para> <para>
@@ -422,10 +427,11 @@ ietf-dhcpv6-types | 2018-01-30 | Imported | |
<listitem> <listitem>
<simpara> <simpara>
<command>model</command> specifies the YANG model / module name. <command>model</command> specifies the YANG model / module name.
<!-- Two bad proposals <!-- @todo: to give people a good out of the box experience, every
(default the corresponding service Kea one). server should have its own default, e.g. for dhcp4 the default
should be kea-dhcp4-server. I understand this doesn't play
Unless explicitly specified, each Kea daemon has its own YANG model. --> well with the SimpleParser defaults mechanism, but we can
figure it out some time later (after 1.5-beta?). -->
</simpara> </simpara>
</listitem> </listitem>