mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-09-02 06:55:16 +00:00
Code Issues Releases Wiki Activity

[5-netconf-doc-config] Final changes

Browse Source
This commit is contained in:
Francis Dupont
2018-10-17 14:29:30 +02:00
parent 6c231d5fc9
commit f0eb96b9ae
1 changed files with 25 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
doc/guide/netconf.xml
View File

@@ -293,19 +293,22 @@ ietf-dhcpv6-types | 2018-01-30 | Imported | |
<listitem> <listitem>
<simpara> <simpara>
The <command>validate-changes</command> controls how Kea monitors The <command>validate-changes</command> controls how Kea monitors
the changes in Sysrepo configuration. Sysrepo offers two stages the changes in Sysrepo configuration. Sysrepo offers two
where Kea could interact: validation and application. The first one stages where Kea could interact: validation and
is called validation (or SR_EV_VERIFY in Sysrepo naming application. The first one is called validation (or
convention). At this stage Kea will get the new configuration being SR_EV_VERIFY event in Sysrepo naming convention). At this
committed and will verify it. If the configuration is incorrect for stage Kea will get the new configuration being committed
whatever reason, Kea servers will reject it, the error will be and will verify it. If the configuration is incorrect for
propagated back to the Sysrepo, which in will return an error to whatever reason, Kea servers will reject it, the error
whoever tried to commit those changes. This step only takes place if will be propagated back to the Sysrepo, which in will
validate-changes is set to true. There is also a second step called return an error to whoever tried to commit those
application (or SR_EV_APPLY in Sysrepo naming convention), where changes. This step only takes place if validate-changes is
the actual configuration is being applied. At this stage Kea can set to true. There is also a second step called
receive the configuration, but it is too late to signal back any application (or SR_EV_APPLY event in Sysrepo naming
errors, as the configuration has been comitted already. 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>
@@ -330,8 +333,10 @@ ietf-dhcpv6-types | 2018-01-30 | Imported | |
} }
</screen> </screen>
Note the alternative to boot with full configurations does not Note the alternative to boot with full configurations does not
allow an easy track of changes, so it not really compatible with allow an easy track of changes or synchronization between the JSON
the YANG / Netconf configuration management paradigm. and YANG sources of configurations. So it not really compatible with
the YANG / Netconf configuration management paradigm where
everything should be performed in YANG.
</para> </para>
<para> <para>
@@ -427,11 +432,9 @@ 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.
<!-- @todo: to give people a good out of the box experience, every For each service the default is the corresponding Kea YANG model,
server should have its own default, e.g. for dhcp4 the default e.g. for <userinput>"dhcp4"</userinput> it is
should be kea-dhcp4-server. I understand this doesn't play <userinput>"kea-dhcp4-server"</userinput>.
well with the SimpleParser defaults mechanism, but we can
figure it out some time later (after 1.5-beta?). -->
</simpara> </simpara>
</listitem> </listitem>
@@ -481,7 +484,8 @@ ietf-dhcpv6-types | 2018-01-30 | Imported | |
User contexts can store arbitrary data as long as it is valid JSON User contexts can store arbitrary data as long as it is valid JSON
syntax and its top level element is a map (i.e. the data must be syntax and its top level element is a map (i.e. the data must be
enclosed in curly brackets). They are accepted at the Netconf entry, enclosed in curly brackets). They are accepted at the Netconf entry,
managed service entry and control socket scopes. i.e. below the toplevel, managed service entry and control socket
entry scopes.
</para> </para>
<para> <para>