Container delete rpc request

Biswajit84 · December 7, 2020, 5:47am

Hi ,
I have a container user-plane-configuration as below:

container user-plane-configuration {
    description "top level container for user plane configuration";
   uses uplane-conf-group;

 }

I would like to delete all the fields from the container while confd is in running state.
I was trying with below rpc request:

<?xml version="1.0" encoding="UTF-8"?>

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<edit-config>
 <target>
   <running/>
 </target>

 <config>

<user-plane-configuration xmlns:xc="urn:o-ran:uplane-conf:1.0"

user-plane-configuration xc:operation="delete">
</user-plane-configuration>
 </config>
    </edit-config>
  </rpc>

But its not working.Can you figure out the mistake

Regards,
Biswajit

cohult · December 7, 2020, 7:22am

Hi,

Try something like:

$ netconf-console -u oper -p oper --edit-config=-<<<'<user-plane-configuration xmlns="urn:o-ran:uplane-conf:1.0" xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0" xc:operation="delete"/>'

Regards

Biswajit84 · December 7, 2020, 7:59am

Hi Conny,
Thanks a lot for your valuable input.
WIth the provided command,its working fine.But i have modified the xml and tried .But its throughing error :

 <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">

<rpc-error>
<error-type>application</error-type>
<error-tag>operation-failed</error-tag>
<error-severity>error</error-severity>
<error-message xml:lang="en">Internal error</error-message>
</rpc-error>
</rpc-reply>

Modified Xml:

       <?xml version="1.0" encoding="UTF-8"?>
       <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
    <edit-config>
   <target>
  <running/>
</target>

<config>

<user-plane-configuration xmlns="urn:o-ran:uplane-conf:1.0"
xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0" xc:operation="delete">
</user-plane-configuration> 
</config>
</edit-config>
</rpc>

If you can figure out the necessary changes required in the xml then it will be helpful.

Regards,
Biswajit

cohult · December 7, 2020, 8:45am

Turn on the netconf.trace in your confd.conf and check the difference between delete I provided using netconf-console and the delete your client sends to ConfD.

As netconf-console by default assign the “nc” prefix to “urn:ietf:params:xml:ns:netconf:base:1.0” , you can simplify that command to somthing like:

$ netconf-console -u oper -p oper --edit-config=-<<<'<user-plane-configuration xmlns="urn:o-ran:uplane-conf:1.0" nc:operation="delete"/>'

So in your confd.conf:

    <netconfTraceLog>
      <enabled>true</enabled>
      <filename>./netconf.trace</filename>
      <format>raw</format>
    </netconfTraceLog>

Run your client’s command and the netconf-console command, and compare using the netconf.trace

Biswajit84 · December 7, 2020, 10:25am

Hi Conny,
I could reproduce the issue with command line also. This time i have enabled netconf.trace also.
So before pushing any configuration if i execute the command:

~buildtools/confd/7.3/x86_64/bin/netconf-console-tcp --host=10.10.11.172 -port=2023 -u oper -p oper --edit-config=-<<<'<user-plane-configuration xmlns="urn:o-ran:uplane-conf:1.0" xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0" xc:operation="delete"/>'

I am getting rpc OK on client.
But after pushing configuration,when i execute the error as below:

~buildtools/confd/7.3/x86_64/bin/netconf-console-tcp --host=10.10.11.172 -port=2023 -u oper -p oper --edit-config=-<<<'<user-plane-configuration xmlns="urn:o-ran:uplane-conf:1.0" 
xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0" xc:operation="delete"/>'
 <?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<rpc-error>
<error-type>application</error-type>
<error-tag>operation-failed</error-tag>
<error-severity>error</error-severity>
<error-message xml:lang="en">Internal error</error-message>
</rpc-error> 
</rpc-reply>

Can you please suggest what could be the issue.

Regards,
Biswajit

cohult · December 7, 2020, 7:01pm

I suggest you check your developer log to begin with. Make sure you have set the developerLogLevel to trace in confd.conf.

Regards

Biswajit84 · December 8, 2020, 5:04am

Hi Conny,
I have enabled the developerLogLevel to trace and found that there is error: " rollback file error".
Below is the complete log when i executed the command provided by you. If you can figure out what could be the issue then it will be helpful.

 confd commit progress db=running usid=17 thandle=5014: applying transaction...
 <DEBUG> 8-Dec-2020::04:58:35.447 fxt01200012 confd[8468]: confd commit progress db=running usid=17 
thandle=5014: entering validate phase for running...
<DEBUG> 8-Dec-2020::04:58:35.447 fxt01200012 confd[8468]: confd commit progress db=running usid=17 
thandle=5014: grabbing transaction lock...
<DEBUG> 8-Dec-2020::04:58:35.448 fxt01200012 confd[8468]: devel-c new_usess db request daemon id: 1
<DEBUG> 8-Dec-2020::04:58:35.448 fxt01200012 confd[8468]: devel-c db reply daemon id: 1
<DEBUG> 8-Dec-2020::04:58:35.449 fxt01200012 confd[8468]: devel-c new_trans request daemon id: 1 thandle: 
5014
<DEBUG> 8-Dec-2020::04:58:35.459 fxt01200012 confd[8468]: devel-c new_trans succeeded daemon id: 1 
session id: 5014 worker id: 9
<DEBUG> 8-Dec-2020::04:58:35.460 fxt01200012 confd[8468]: confd commit progress db=running usid=17 
thandle=5014: grabbing transaction lock ok
<DEBUG> 8-Dec-2020::04:58:35.461 fxt01200012 confd[8468]: confd commit progress db=running usid=17 
thandle=5014: creating rollback file...
<DEBUG> 8-Dec-2020::04:58:35.520 fxt01200012 confd[8468]: confd commit progress db=running usid=17 
thandle=5014: creating rollback file error
<DEBUG> 8-Dec-2020::04:58:35.521 fxt01200012 confd[8468]: confd commit progress db=running usid=17 
thandle=5014: releasing transaction lock
<DEBUG> 8-Dec-2020::04:58:35.523 fxt01200012 confd[8468]: confd commit progress db=running usid=17 
thandle=5014: leaving validate phase for running
<DEBUG> 8-Dec-2020::04:58:35.524 fxt01200012 confd[8468]: confd commit progress db=running usid=17 
thandle=5014: applying transaction done
<DEBUG> 8-Dec-2020::04:58:35.525 fxt01200012 confd[8468]: devel-c close_trans request daemon id: 1 
  session id: 5014
<DEBUG> 8-Dec-2020::04:58:35.526 fxt01200012 confd[8468]: devel-c close_trans succeeded daemon id: 1 
 session id: 5014
 <DEBUG> 8-Dec-2020::04:58:35.530 fxt01200012 confd[8468]: devel-c close_usess db request daemon id: 1
 <DEBUG> 8-Dec-2020::04:58:35.531 fxt01200012 confd[8468]: devel-c db reply daemon id: 1

Regards,
Biswajit

cohult · December 8, 2020, 8:42am

Hi Biswajit,

Any more info in the confd.log on this particular rollback file creation error?
What’s the content of the error log? I.e. the output of:
$ confd --printlog confderr.log.1

Regards

Biswajit84 · December 8, 2020, 10:21am

Hi Conny,
I have enabled confd.log in confd.conf.
confd.log shows:

<ERR> 8-Dec-2020::10:07:50.086 fxt01200012 confd[2516]: - Error while creating rollback file: 
 /var/confd/rollback/rollback0.prepare: Internal error

confd --printlog /tmp/confderr.log. shows :

rollback:769: cs_trans_rng:save_delta_rev(): error:undef
[{cli_common_dm,recalc_single_leaf,
** [undefined,false,[],undefined,[],**
** [{<<“LLTE-DCH-0”>>},**
** ‘low-level-tx-endpoints’,**
** [‘urn:o-ran:uplane-conf:1.0’|‘user-plane-configuration’]]],**
** []},**

{cs_trans_rng,get_cs2,10,[{file,“cs_trans_rng.erl”},{line,3121}]},
{cs_trans_rng,get_cs_delta1,8,[{file,“cs_trans_rng.erl”},{line,6469}]},
{cs_trans_rng,’-save_delta_rev/14-fun-4-’,19,
[{file,“cs_trans_rng.erl”},{line,5894}]},
{cs_trans_diff_iterate,sh_diff_iterate_x,10,
[{file,“cs_trans_diff_iterate.erl”},{line,323}]},
{xds_ram,tts_fold_children,7,[{file,“xds_ram.erl”},{line,1231}]},
{cs_trans_diff_iterate,sh_diff_iterate_x,10,
[{file,“cs_trans_diff_iterate.erl”},{line,491}]},
{xds_ram,tts_fold_children,7,[{file,“xds_ram.erl”},{line,1231}]},
{cs_trans_diff_iterate,sh_diff_iterate_x,10,
[{file,“cs_trans_diff_iterate.erl”},{line,499}]},
{xds_ram,tts_fold_children,7,[{file,“xds_ram.erl”},{line,1231}]},
{cs_trans_diff_iterate,sh_diff_iterate_x,10,
[{file,“cs_trans_diff_iterate.erl”},{line,499}]},
{cs_trans_diff_iterate,sh_diff_iterate,7,
[{file,“cs_trans_diff_iterate.erl”},{line,131}]},
{cs_trans_rng,’-save_delta_rev/14-fun-11-’,3,
[{file,“cs_trans_rng.erl”},{line,6067}]},
{cs_trans_rng,save_delta_rev,14,[{file,“cs_trans_rng.erl”},{line,6065}]},
{rollback,create_pending,11,[{file,“rollback.erl”},{line,731}]},
{rollback,create_pending,7,[{file,“rollback.erl”},{line,626}]},
{cs_trans,do_rollback,8,[{file,“cs_trans.erl”},{line,16506}]},
{cs_trans,sh_validate2,13,[{file,“cs_trans.erl”},{line,11929}]},
{cs_trans,sh_validate0,7,[{file,“cs_trans.erl”},{line,11800}]},
{cs_trans,handle_call,3,[{file,“cs_trans.erl”},{line,4643}]},
{gen_server,try_handle_call,4,[{file,“gen_server.erl”},{line,652}]},
{gen_server,handle_msg,6,[{file,“gen_server.erl”},{line,681}]},
{proc_lib,init_p_do_apply,3,[{file,“proc_lib.erl”},{line,247}]}]

fxt01200012 / # cat /var/confd/rollback/rollback0.prepare
#Created by: oper
#Date: 2020-12-08 10:07:50
#Via: netconf
#Type: delta
#Label:
#Comment:
#No: 10069
#TransactionId: 5052
#Hostname: fxt01200012

user-plane-configuration {
low-level-tx-endpoints LLTE-DCH-0 {

fxt01200012 / # cat /var/confd/rollback/rollback0
#Created by: admin
#Date: 2020-12-08 08:55:49
#Via: netconf
#Type: delta
#Label:
#Comment:
#No: 10067
#TransactionId: 5032
#Hostname: fxt01200012

interfaces {
delete:
interface " eth0";
}
user-plane-configuration {
delete:
low-level-tx-endpoints LLTE-DCH-0;
delete:
low-level-tx-endpoints LLTE-DCH-1;
}

Regards,
Biswajit

Biswajit84 · December 10, 2020, 3:31pm

Hi Conny,
Did you get any clue?

Also Can you please review the confd.conf which i am using.

<confdConfig xmlns="http://tail-f.com/ns/confd_cfg/1.0">
<loadPath>
 <dir>/etc/confd/</dir>
<!--
<dir>/usr/confd/etc/confd/</dir>
<dir>/usr/confd/etc/confd/System</dir>
<dir>/usr/confd/etc/confd/Imported-Models</dir>
<dir>/usr/confd/etc/confd/Common-Models</dir>
<dir>/usr/confd/etc/confd/Common-Models/System</dir>
<dir>/usr/confd/etc/confd/Common-Models/Operations</dir>
<dir>/usr/confd/etc/confd/Common-Models/Interfaces</dir>
<dir>/usr/confd/etc/confd/Common-Models/Sync</dir>
<dir>/usr/confd/etc/confd/RU-Specific-Models</dir>
<dir>/usr/confd/etc/confd/RU-Specific-Models/Radio</dir>
<dir>/usr/confd/etc/confd/RU-Specific-Models/Operations</dir>
 -->
</loadPath>

 <!--
  This is where ConfD writes persistent state data.  Currently the
  only state files are 'running.invalid' which exists only if the
  running database status is invalid, which it will be if one of
  the database implementation fails during the two-phase commit
  protocol, and 'global.data' which is used to store some data
  that needs to be retained across reboots.
  -->
  <stateDir>/nand/confd/state</stateDir>

  <cdb>
  <enabled>true</enabled>
  <dbDir>/var/confd/cdb</dbDir>

  <clientTimeout>PT30S</clientTimeout>

  <operational>
  <enabled>true</enabled>
  </operational>

 </cdb>

    <encryptedStrings>
<DES3CBC>
  <key1>0123456789abcdef</key1>
  <key2>0123456789abcdef</key2>
  <key3>0123456789abcdef</key3>
  <initVector>0123456789abcdef</initVector>
</DES3CBC>

<AESCFB128>
  <key>0123456789abcdef0123456789abcdef</key>
  <initVector>0123456789abcdef0123456789abcdef</initVector>
</AESCFB128>

<AES256CFB128>
  <key>0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef</key>
</AES256CFB128>
</encryptedStrings>

<logs>
<!--
    Shared settings for how to log to syslog.
    Each log can be configured to log to file and/or syslog.  If a
    log is configured to log to syslog, the settings below are used.
-->
<syslogConfig>
  <!-- facility can be 'daemon', 'local0' ... 'local7' or an integer -->
  <facility>daemon</facility>
  <!-- if udp is not enabled, messages will be sent to local syslog -->
  <udp>
    <enabled>false</enabled>
    <host>syslogsrv.example.com</host>
    <port>514</port>
  </udp>
</syslogConfig>

<!--
    'confdlog' is a normal daemon log.  Check this log for
    startup problems of confd itself.
    By default, it logs directly to a local file, but it can be
    configured to send to a local or remote syslog as well.
-->
<confdLog>
  <enabled>true</enabled>
  <file>
    <enabled>true</enabled>
    <name>/var/confd/log/confd.log</name>
  </file>
  <syslog>
    <enabled>true</enabled>
  </syslog>
</confdLog>

<!--
    The developer logs are supposed to be used as debug logs
    for troubleshooting user-written C code.  Enable
    and check these logs for problems with validation code, etc.
  -->
 <developerLog>
  <enabled>true</enabled>
  <file>
    <enabled>true</enabled>
    <name>/var/confd/log/devel.log</name>
  </file>
  <syslog>
    <enabled>true</enabled>
  </syslog>
</developerLog>
<developerLogLevel>trace</developerLogLevel>
<auditLog>
  <enabled>true</enabled>
  <file>
    <enabled>true</enabled>
    <name>/var/confd/log/confd-audit.log</name>
  </file>
  <syslog>
    <enabled>true</enabled>
  </syslog>
</auditLog>

<!--
    The netconf log can be used to troubleshoot NETCONF operations,
    such as checking why e.g. a filter operation didn't return the
    data requested.
-->
<netconfLog>
  <enabled>true</enabled>
  <file>
    <enabled>true</enabled>
    <name>/var/log/netconf.log</name>
  </file>
  <syslog>
    <enabled>true</enabled>
  </syslog>
</netconfLog>

<jsonrpcLog>
  <enabled>true</enabled>
  <file>
    <enabled>false</enabled>
    <name>/var/log/jsonrpc.log</name>
  </file>
  <syslog>
    <enabled>true</enabled>
    <facility>daemon</facility>
  </syslog>
</jsonrpcLog>

<webuiAccessLog>
  <enabled>false</enabled>
  <dir>/var/log/confd</dir>
</webuiAccessLog>

<snmpLog>
  <enabled>false</enabled>
  <file>
    <enabled>true</enabled>
    <name>/var/confd/log/snmp.log</name>
  </file>
  <syslog>
    <enabled>true</enabled>
  </syslog>
</snmpLog>

<netconfTraceLog>
  <enabled>true</enabled>
  <filename>/var/confd/log/netconf.trace</filename>
</netconfTraceLog>

<!--
    The error log is used for internal logging from the confd
    daemon.  It is used for troubleshooting the confd daemon
    itself, and should normally be disabled.
-->
<errorLog>
  <enabled>true</enabled>
  <filename>/var/confd/log/confderr.log</filename>
  <maxSize>S10M</maxSize>
</errorLog>

<!--
    Progress tracing must be enabled here and then configured
    according to tailf-progress.yang.
-->
<progressTrace>
  <enabled>true</enabled>
  <dir>/var/confd/log</dir>
</progressTrace>
</logs>

<!-- Defines which datastores confd will handle. -->
<datastores>
<startup>
  <enabled>false</enabled>
</startup>

<candidate>
  <enabled>true</enabled>
  <implementation>confd</implementation>
  <storage>auto</storage>
  <filename>/var/confd/candidate/candidate.db</filename>
</candidate>

<running>
  <access>read-write</access>
</running>

</datastores>

<enableAttributes>false</enableAttributes>

<sessionLimits>

   <!--
    These parameters controls the maximum number of concurrent
    sessions towards ConfD. 'context' is 'cli' or 'netconf'.
  -->
<maxSessions>unbounded</maxSessions>
<sessionLimit>
  <context>cli</context>
  <maxSessions>100</maxSessions>
</sessionLimit>
 <sessionLimit>
  <context>netconf</context>
  <maxSessions>unbounded</maxSessions>
</sessionLimit>
</sessionLimits>

<aaa>
<sshServerKeyDir>/nand/etc/confd/ssh</sshServerKeyDir>

<!-- See man page confd_aaa_bridge(1) for a description of this -->
<aaaBridge>
  <enabled>false</enabled>
  <file>/etc/confd/aaa.conf</file>
</aaaBridge>

<pam>
  <enabled>true</enabled>
  <service>system-auth</service>
</pam>

<localAuthentication>
  <enabled>true</enabled>
</localAuthentication>

</aaa>

<rollback>
<!--
     To enable rollback file creation set enabled to true.
     You also have to configure a directory for the rollback files.
     A rollback file (rollback0-rollback<historySize>) will be
     created whenever a new configuration is committed
-->
<enabled>true</enabled>
<directory>/var/confd/rollback</directory>
<historySize>50</historySize>
<!-- If "full" is specified, then a full configuration dump is
     stored in each rollback file.  Rollback file 0 will always
     contain the running configuration.  If "delta" is used, then
     only the changes are stored in the rollback file. Rollback
     file 0 will contain the changes from the last configuration.

     Using deltas is more space and time efficient for large
     configurations.  Full rollback files are more robust when
     multiple external databases are used. If the external
     databases becomes inconsistent a previous configuration can
     always be restored using a full rollback file.
-->
<type>delta</type>
</rollback>

<cli>
<!-- If a table is too wide to fit in the terminal it will
     instead be shown as a path - value list. When table
     overflow is allowed it will be displayed as a table
     even when the table is to wide to fit on the screen
  -->
<allowTableOverflow>false</allowTableOverflow>
<allowTableCellWrap>false</allowTableCellWrap>
<!-- If showAllNs is true then all elem names will be prefixed
     with the namespace prefix in the CLI. This is visible
     when setting values and when showing the configuratin
-->
<showAllNs>false</showAllNs>
<!-- To log all CLI activity use 'all', to only log
     attempts to execute unauthorized commands, use denied,
     for only logging actually executed commands use allowed,
     and for no logging use 'none'
-->
<!-- Controls if transactions should be used in the CLI or not.
     Old style Cisco IOS does not use transactions, Juniper and
     Cisco XR does. The commit command is disabled if transactions
     are disabled. All modifications are applied immediately.
     NOTE: this requires that you have default values for ALL
     settings and no complex validation rules.
-->
<transactions>true</transactions>
<auditLogMode>denied</auditLogMode>
<completionShowMax>100</completionShowMax>
<withDefaults>false</withDefaults>
<defaultPrefix></defaultPrefix>
<showDefaults>false</showDefaults>
<docWrap>true</docWrap>
<infoOnTab>true</infoOnTab>
<infoOnSpace>true</infoOnSpace>
<newLogout>true</newLogout>
<!-- Prompt1 is used in operational mode and prompt2 in
     configuration mode. The string may contain a number of
     backslash-escaped special characters that are decoded
     as follows:

          \d     the date in YYYY-MM-DD format (e.g., "2006-01-18")
          \h     the hostname up to the first `.'
          \H     the hostname
          \t     the current time in 24-hour HH:MM:SS format
          \T     the current time in 12-hour HH:MM:SS format
          \@     the current time in 12-hour am/pm format
          \A     the current time in 24-hour HH:MM format
          \u     the username of the current user
          \m     mode name in the Cisco-style CLI
          \M     mode name inside parenthesis if set
-->
<prompt1>\u@\h\M \t> </prompt1>
<prompt2>\u@\h\M \t% </prompt2>
<cPrompt1>\h\M# </cPrompt1>
<cPrompt2>\h(\m)# </cPrompt2>
<idleTimeout>PT30M</idleTimeout>
<commandTimeout>infinity</commandTimeout>
<spaceCompletion>
  <enabled>true</enabled>
</spaceCompletion>
<showLogDirectory>/var/log</showLogDirectory>
<autoWizard>
  <enabled>true</enabled>
</autoWizard>
<ssh>
  <enabled>true</enabled>
  <ip>0.0.0.0</ip>
  <port>2024</port>
</ssh>
<showEmptyContainers>false</showEmptyContainers>
<cTab>false</cTab>
<cHelp>true</cHelp>
<!-- Mode name style is only used by the Cisco style CLIs.
     It controls how to calculate the mode name when entering
     a submode. If set to 'full' then the entire path will be
     used in the mode name, if set to 'short' then only the
     last element + dynamic key will be used. If 'two' then
     the two last modes will be displayed.
-->
<modeNameStyle>short</modeNameStyle>
<messageMaxSize>10000</messageMaxSize>
<historyMaxSize>1000</historyMaxSize>
<historyRemoveDuplicates>false</historyRemoveDuplicates>
<compactShow>false</compactShow>
<compactStatsShow>false</compactStatsShow>
<reconfirmHidden>false</reconfirmHidden>
<enumKeyInfo>false</enumKeyInfo>
<columnStats>false</columnStats>
<allowAbbrevKeys>true</allowAbbrevKeys>
<allowAbbrevParamNames>false</allowAbbrevParamNames>
<allowAbbrevEnums>true</allowAbbrevEnums>
<allowCaseInsensitiveEnums>true</allowCaseInsensitiveEnums>
<enableDisplayLevel>true</enableDisplayLevel>
<enableLoadMerge>true</enableLoadMerge>
<defaultDisplayLevel>99999999</defaultDisplayLevel>
<unifiedHistory>false</unifiedHistory>
<modeInfoInAAA>false</modeInfoInAAA>
<quoteStyle>backslash</quoteStyle>
<caseInsensitive>false</caseInsensitive>
<ignoreLeadingWhitespace>false</ignoreLeadingWhitespace>
<explicitSetCreate>false</explicitSetCreate>
<mapActions>both</mapActions>

false /var/confd/webui/docroot true 0.0.0.0 8008

  <ssl>
    <enabled>false</enabled>
    <ip>0.0.0.0</ip>
    <port>8888</port>
    <keyFile>/var/confd/webui/cert/host.key</keyFile>
    <certFile>/var/confd/webui/cert/host.cert</certFile>
  </ssl>
</transport>
</webui>

true

<transport>
  <ssh>
    <enabled>true</enabled>
    <ip>0.0.0.0</ip>
    <!-- Note that the standard port for NETCONF over SSH is 830 -->
    <port>2022</port>
  </ssh>

  <!--
      NETCONF over TCP is not standardized, but it can be useful
      during development in order to use e.g. netcat for scripting.
  -->
  <tcp>
    <enabled>true</enabled>
    <ip>0.0.0.0</ip>
    <port>2023</port>
  </tcp>
</transport>

<capabilities>
  <!-- enable only if /confdConfig/datastores/startup is enabled -->
  <startup>
    <enabled>false</enabled>
  </startup>

  <!-- enable only if /confdConfig/datastores/candidate is enabled -->
  <candidate>
    <enabled>true</enabled>
  </candidate>

  <confirmed-commit>
    <enabled>true</enabled>
  </confirmed-commit>

  <!--
       enable only if /confdConfig/datastores/running is read-write
  -->
  <writable-running>
    <enabled>true</enabled>
  </writable-running>

  <rollback-on-error>
    <enabled>true</enabled>
  </rollback-on-error>

  <!-- Turn on the URL capability options you want to support -->
  <url>
    <enabled>true</enabled>
    <file>
      <enabled>true</enabled>
      <rootDir>/var/confd/state</rootDir>
    </file>
    <ftp>
      <enabled>true</enabled>
    </ftp>
  </url>

  <xpath>
    <enabled>true</enabled>
  </xpath>

  <!--
      Enable this to turn on NETCONF Notifications support.
  -->
  <notification>
    <enabled>true</enabled>
    <!--
        Enable this to make the agent handle RPCs while sending
        notifications.
    -->
    <interleave>
      <enabled>true</enabled>
    </interleave>
  </notification>

</capabilities>

 <!--
     If extendedSessions are enabled, all ConfD sessions can be
     terminated using <kill-session>, i.e. not only can other
     NETCONF session be terminated, but also CLI sessions, WebUI
     sessions etc.  If such a session holds a lock, its session
     id will be returned in the <lock-denied>, instead of "0".

     Strictly speaking, this extension is not covered by the
     NETCONF specification; therefore it's false by default.
-->
<extendedSessions>false</extendedSessions>

</netconf>
<notifications>
<eventStreams>
  <stream>
<name>NETCONF</name>
<description>Example notifications</description>
<replaySupport>true</replaySupport>
    <builtinReplayStore>
  <!-- enableBuiltinReplayStore -->
      <enabled>true</enabled>
      <dir>/tmp</dir>
      <maxSize>S1M</maxSize>
      <maxFiles>5</maxFiles>
    </builtinReplayStore>
  </stream>
</eventStreams>
</notifications>
<snmpAgent>
<!-- Enable only if snmp agent should be started -->
<enabled>false</enabled>
<!--
    Configure the IP address and port that the SNMP Agent
    should listen to
-->
<ip>0.0.0.0</ip>
<port>4000</port>
<!-- Differentiated Services Code Point, 6 bits -->
<dscp>0</dscp>
<!--
    List mibs that should be loaded into the SNMP Agent
    at startup.
    With no mibs loaded, the SNMP agent will start with the built-in
    standard mibs only.  See the User's Guide for details.
-->
<mibs>
  <!--
  <file>/etc/confd/mibs/EXAMPLE-MIB.bin</file>
  -->
</mibs>
<!--
     The SNMP Engine ID is a hexList and can be constructed
     in many ways. See the SNMP-FRAMEWORK-MIB for more
     information about this.
     The MaxMessageSize can be set, but should normally not be
     modified.
-->
<snmpEngine>
  <snmpEngineID>80:00:61:81:05:01</snmpEngineID>
</snmpEngine>
<system>
  <sysDescr>Tail-f ConfD agent</sysDescr>
  <sysObjectID>1.3.6.1.4.1.24961</sysObjectID>
  <sysServices>72</sysServices>
  <!--  The sysORTable stores capabilities that this agent supports -->
  <sysORTable>
    <!--
       Example of a capability:
       <sysOREntry>
         <sysORIndex>1</sysORIndex>
         <sysORID>1.3.6.1.4.1.24961.1</sysORID>
         <sysORDescr>Example capability</sysORDescr>
       </sysOREntry>
    -->
  </sysORTable>
</system>
</snmpAgent>
</confdConfig>

cohult · December 11, 2020, 10:37am

I see you filed a ticket with Tail-f ConfD support in RT. Good. That’s the next step here.