Description
ietf-restconf has this modeling beauty:
container operations {
description
"Container for all operation resources.
Each resource is represented as an empty leaf with the
name of the RPC operation from the YANG 'rpc' statement.
For example, the 'system-restart' RPC operation defined
in the 'ietf-system' module would be represented as
an empty leaf in the 'ietf-system' namespace. This is
a conceptual leaf and will not actually be found in
the module:
module ietf-system {
leaf system-reset {
type empty;
}
}
To invoke the 'system-restart' RPC operation:
POST /restconf/operations/ietf-system:system-restart
To discover the RPC operations supported by the server:
GET /restconf/operations
In XML, the YANG module namespace identifies the module:
<system-restart
xmlns='urn:ietf:params:xml:ns:yang:ietf-system'/>
In JSON, the YANG module name identifies the module:
{ 'ietf-system:system-restart' : [null] }
";
}
This special node should not be a container, but rather an explicit extension, so that support can be hooked into YANG parser machinery. Fortunately ietf-restconf defines (and uses) an extension, so we at least have that hook available.
Update YangDataStatementSupport to explicitly recognize this feature and perform the required magic – luckily there are no RPCs in that model, hence we should be able to rely on other models finishing full declaration and scraping RPCs from there.
Attachments
Issue Links
- is blocked by
-
YANGTOOLS-1372 Add support for purely-effective substatements
-
- Resolved
-
-
YANGTOOLS-1371 Expose available StatementSupports from StmtContext
-
- Resolved
-
-
YANGTOOLS-1381 Parser reactor does not support chained prerequisites
-
- Resolved
-
- relates to
-
NETCONF-822 Discover RPC operation through RESTCONF is failing with response 500
-
- Resolved
-