I created a yang data model with an rpc action (without using tailf annotation action). Something like this:
rpc some_action {
tailf:actionpoint some_callpoint;
input {
container foo {
leaf bar {
type string;
}
}
output {
leaf result {
type string;
}
}
}
I am trying to return to confd the result about the action. I have noticed that in the examples (7-actions) you use the generated python file from yang data model (config_ns.py) like this:
result = [
make_tag_value(ns.hash, ns.config_time, res)
]
Is there any other way to find the result’s leaf tag except from the generated file? Params list has no information about the output statement but only for the input statement.
Hello. Yes, params are input params of the action, so it cannot contain output parameters.
Regarding hash tag. In your action handler you know what should be returned, so it is not clear why is it problem to create result with hashes from generated python file. This file is always present and is essential
part of the developed ConfD application. Please, can you dscribe what prevents you to use generated *_ns.py file?
Hello,
Thanks for your quick response. It is very complicated to explain why the ‘*_ns.py’ file is not present where the external provider is executed. As you said the file is successfully generated but I cannot import it. In conclusion, there is no other way to find hash tag, even if I try to load schemas from maapi? Maybe this is not possible because confd keypath is NULL in my case ?? (from documentation: it is a NULL pointer for an action defined via rpc)
Regards,
Marc
I’m afraid I can’t help you with the Python equivalent, but since you quote the documentation for the C API:-), I’ll give an answer in terms of that, and maybe you can figure out the Python (or @mnovak might be able to translate…) . The output nodes are definitely part of the loaded schema, both for action and rpc - the reason for the NULL pointer is that the keypath (kp) argument passed to the action() callback is actually the path to the parent node, while the action/rpc itself is given in the name argument - and by definition, an rpc does not have a parent.
In the schema, both the input and the output nodes are direct children of the action/rpc node - the input nodes have the CS_NODE_IS_PARAM flag set, while the output nodes have CS_NODE_IS_RESULT set. The confd_cmd tool has a nice command dump_schema, that can be used to get a condensed view of the schema - the command confd_cmd -c 'dump_schema /some_action' will show you what is there for your rpc.
And in the C API, you could use e.g. struct confd_cs_node *csp = confd_cs_node_cd(NULL, "/some_action/result"); to get the node for your “result” leaf, with csp->ns and csp->tag being the hash values for the namespace and “tag”. (Caveat: if your input and output have same-named nodes, you will have to traverse the children to find the “param” vs “result” node.)
Hello,
The solution that has been provided worked excellent!
Τo get to the bottom of the conversation, I would like to ask a simple question. Is there any restriction when in the output statement there is an enum type? Something like this:
…
output {
leaf result {
type enumeration {
enum ok;
enum not-ok;
}
In the documentation there is no special reference about enumerations.
But when I am trying to return something to cond I get “—ERROR—” instead of the enum. Am I missing something?
There is nothing special with enumerations in ‘output’, but there is a “somewhat special” (but not unique) thing with enumerations in general, and that is that the translation between the string representation and the “value” representation (_confd.Value in Python I believe) requires schema information. ConfD uses the C_ENUM_VALUE type + the integer values assigned according to the YANG spec for the value representation, i.e. in your case “ok” corresponds to the integer 0 and “not-ok” to the integer 1 - but some other enumeration type may have “ok” and “not-ok” corresponding to completely different integer values.
Anyway, I guess you are trying to return the string representation of the enum values, but the TagValue list wants the values. Since you’re already familiar with using the schema information, it may be enough to point you to _confd.Value.str2val() as the way to convert strings to values…
Btw, you should have gotten some slightly more detailed information about the problem with your output values in the devel.log.
Hello per,
Yes you are correct! The str2val() function should have been used. I was using _confd.Value instead.
Thanks again per for you instant help!!