I have Yang schema supplied by an external company that consist entirely of grouping with submodules doing the same. Whenever I use confd_find_cs_root with the namespace generated from header produced by confdc it returns -1. This indicating to me the schema isn’t present? using the same call with an example yang schema from your examples it work fine. My question, can confd handle schema composed entirely of grouping? and what exactly i need to to correct this my schema so that confd can work.
From the YANG 1.1 RFC7950 section 7.12 The “grouping” Statement:
The “grouping” statement is not a data definition statement and, as such, does not define any nodes in the schema tree. A grouping is like a “structure” or a “record” in conventional programming languages. Once a grouping is defined, it can be referenced in a “uses” statement (see Section 7.13).
From section 7.13 The “uses” statement:
The effect of a “uses” reference to a grouping is that the nodes
defined by the grouping are copied into the current schema tree and
are then updated according to the “refine” and “augment” statements.The identifiers defined in the grouping are not bound to a namespace
until the contents of the grouping are added to the schema tree via a
“uses” statement that does not appear inside a “grouping” statement,
at which point they are bound to the namespace of the current module.
Our yang has “uses” defined inside “grouping” statement and again inside “submodules” with “grouping” statements and does not make use of any “refine” and/or “augment” statements.
module _3gpp_common_ep_rp {
yang-version 1.1;
namespace “urn:3gpp:tsg:sa5:nrm:EP_RP”;
prefix “eprp3gpp”;
import _3gpp_common_top { prefix top3gpp; }
import _3gpp_common_vs_data_container {prefix vsData3gpp; }
import _3gpp_common_nrm_types { prefix nrmtype3gpp; }
//import ietf-inet-types { prefix inet; }
import _3gpp_common_measurements { prefix meas3gpp; }
description "common/basic MF class to be inherited/reused by other child MF classes ";
revision 2018-07-31 {
description "Initial revision";
}
grouping address-local {
leaf ip_addr {
//type inet:ip-address;
type string {
pattern
'(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+ '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
+ '(%[\p{N}\p{L}]+)?';
}
}
leaf vlan_id {
type uint16;
mandatory "false";
}
}
grouping EP_RP {
description "";
uses top3gpp:Top;
leaf id {
description "";
type nrmtype3gpp:t_dn;
}
leaf userLabel {
description "";
mandatory "false";
type string;
}
leaf farEndEntity {
mandatory "false";
type nrmtype3gpp:t_dn;
}
list vsDataContainer {
key "id";
min-elements "0";
max-elements 21;
**uses vsData3gpp:VsDataContainer;**
}
uses meas3gpp:Measurements;
}
grouping EP_XX {
description "as all EPs defined in NGRAN and 5GC have same attributes, define a common EP for all endpoints for reusing";
uses EP_RP;
container localAddress {
presence "true";
description "";
uses address-local;
}
leaf remoteAddress {
description "";
mandatory "false";
//type inet:ip-address;
type string {
pattern
'(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+ '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
+ '(%[\p{N}\p{L}]+)?';
}
}
}The point I was attempting to make with those quotes from the YANG 1.1 RFC was to show how the grouping statements in the YANG model you refer to are not added to the schema tree.
They need to be added via a “uses” statement that does not appear inside a “grouping” statement to be part of the schema.
Is there a way of listing all namespaces defined in confD? In, addition how can program receive events for all user namespaces?
A few examples:
NETCONF:
yang-revision 1.1 modules:
$ netconf-console --get -x /yang-library
yang-revision 1.0 modules:
$ netconf-console --hello
All YANG modules (ConfD proprietary path):
$ netconf-console --get -x /confd-state/loaded-data-models/data-model
RESTCONF:
yang-revision 1.1 modules:
$ curl -s -u admin:admin -H "Accept: application/yang-data+json" http://localhost:8008/restconf/data/ietf-yang-library:yang-library
All YANG modules (ConfD proprietary path):
$ curl -s -u admin:admin -H "Accept: application/yang-data+json" http://localhost:8008/restconf/data/tailf-confd-monitoring:confd-state/loaded-data-models/data-model/namespace
MAAPI:
$ confd_load -o -Fp -p /confd-state/loaded-data-models/data-model/namespace
$ confd_load -o -Fo -p /confd-state/loaded-data-models/data-model
CLI:
$ confd_cli -u admin -C
$ show confd-state loaded-data-models data-model namespace
if you are referring to subscriber events when config or operational data change if your path into the schema is “/” the root you will receive subscriber events for all changes. Search for cdb_subscribe / cdb_oper_subscribe in the ConfD UG.
I recommend the ConfD Evaluation Kick Start Guide for a quick intro to ConfD.
Thank you for response. I was more than helpful. I found schema definitions, and now have more questions. I need to issue “cdb_subscribe2” and specify root for this yang and don’t think confD can the way this yang model is constructed.
It appear confD requires something “container/list/leaf” ?
Currently I specify “0” zero for namespace and “/” for the root path. I can already see problems with maapi_set_values or maapi_set_object without root path? and may need to speak with vendor about yang model and compatibility with confD and need more info from you guys.
**_3gpp_common_ep_rp** 2018-07-31 urn:3gpp:tsg:sa5:nrm:EP_RP eprp3gppYou can become friends with the ConfD examples, the confd_cmd and confd_load tools source code, man pages, and UG to find answers on how to use the API.
$ find $CONFD_DIR/examples.confd/ -name "*.c" |xargs grep -n cdb_subscribe2
confd-7.5.1/examples.confd//cdb_subscription/twophase/twophase.c:256: ret = cdb_subscribe2(ss, subtype, 0, prio, &sid, 0, argv[0]);
$ find $CONFD_DIR/src/confd/tools -name "*.c" |xargs grep -n cdb_subscribe2
confd-7.5.1/src/confd/tools/confd_cmd.c:1018: OK(cdb_subscribe2(cs, CDB_SUB_RUNNING_TWOPHASE, 0, prio, &id, 0, argv[0]));
confd-7.5.1/src/confd/tools/confd_cmd.c:1102: OK(cdb_subscribe2(cs, type, 0, prio, &id, 0, argv[0]));
confd-7.5.1/src/confd/tools/confd_cmd.c:1149: OK(cdb_subscribe2(cs, subtype, 0, prio, &id, 0, argv[1]));
confd-7.5.1/src/confd/tools/src/confd_cmd.c:1018: OK(cdb_subscribe2(cs, CDB_SUB_RUNNING_TWOPHASE, 0, prio, &id, 0, argv[0]));
confd-7.5.1/src/confd/tools/src/confd_cmd.c:1102: OK(cdb_subscribe2(cs, type, 0, prio, &id, 0, argv[0]));
confd-7.5.1/src/confd/tools/src/confd_cmd.c:1149: OK(cdb_subscribe2(cs, subtype, 0, prio, &id, 0, argv[1]));
$ man $CONFD_DIR/man/man3/confd_lib_cdb.3 | col -b | sed -n -e '/int cdb_subscribe2/,/int cdb_/ p'
int cdb_subscribe2(int sock, enum cdb_sub_type type, int flags,
int priority, int *spoint, int nspace,
const char *fmt, ...);
int cdb_subscribe(int sock, int priority, int nspace, int *spoint,
int cdb_subscribe2(int sock, enum cdb_sub_type type, int flags,
int priority, int *spoint, int nspace,
const char *fmt, ...);
This function supersedes the current cdb_subscribe() and
cdb_oper_subscribe() as well as makes it possible to use the new two
phase subscription method. The cdb_sub_type is defined as:
enum cdb_sub_type {
CDB_SUB_RUNNING = 1,
CDB_SUB_RUNNING_TWOPHASE = 2,
CDB_SUB_OPERATIONAL = 3
};
The CDB subscription type CDB_SUB_RUNNING is the same as
cdb_subscribe(), CDB_SUB_OPERATIONAL is the same as
cdb_oper_subscribe(), and CDB_SUB_RUNNING_TWOPHASE does a two phase
subscription.
The flags argument should be set to 0, or a combination of:
CDB_SUB_WANT_ABORT_ON_ABORT
Normally if a subscriber is the one to abort a transaction it will
not receive an abort notification. This flags means that this
subscriber wants an abort notification even if it was the one that
called cdb_sub_abort_trans(). This flag is only valid when the
subscription type is CDB_SUB_RUNNING_TWOPHASE.
The two phase subscriptions work like this: A subscriber uses
cdb_subscribe2() with the type set to CDB_SUB_RUNNING_TWOPHASE to
register as many subscription points as required. The
cdb_subscribe_done() function is used to indicate that no more
subscription points will be registered on that particular socket. Only
after cdb_subscribe_done() is called will subscription notifications be
delivered.
Once a transaction enters prepare state all CDB two phase subscribers
will be notified in priority order (lowest priority first, subscribers
with the same priority is delivered in parallel). The
cdb_read_subscription_socket2() function will set type to
CDB_SUB_PREPARE. Once all subscribers have acknowledged the
notification by using the function
cdb_sync_subscription_socket(CDB_DONE_PRIORITY) they will subsequently
be notified when the transaction is committed. The CDB_SUB_COMMIT
notification is the same as the current subscription mechanism, so when
a transaction is committed all subscribers will be notified (again in
priority order).
When a transaction is aborted, delivery of any remaining
CDB_SUB_PREPARE notifications is cancelled. The subscribers that had
already been notified with CDB_SUB_PREPARE will be notified with
CDB_SUB_ABORT (This notification will be done in reverse order of the
CDB_SUB_PREPARE notification). The transaction could be aborted because
one of the subscribers that received CDB_SUB_PREPARE called
cdb_sub_abort_trans(), but it could also be caused for other reasons,
for example another data provider (than CDB) can abort the transaction.
Note
Two phase subscriptions are not supported for NCS.
Note
Operational and configuration subscriptions can be done on the same
socket, but in that case the notifications may be arbitrarily
interleaved, including operational notifications arriving between
different configuration notifications for the same transaction. If
this is a problem, use separate sockets for operational and
configuration subscriptions.
Errors: CONFD_ERR_MALLOC, CONFD_ERR_OS, CONFD_ERR_BADPATH,
CONFD_ERR_NOEXISTS
int cdb_subscribe_done(int sock);