I have a single set of configuration that I want to display in the show command.
The configuration includes: vpn, src-ip, dest-ip, interface name.
None of the fields in the configuration is mandatory. (So, I guess i can’t use list because list needs a mandatory key leaf)
I want to implement a show command to display this set of configured values. What would be the right construct to do so?
If all the associated configuration attributes are defined within the same container, you will be able to do a “show running-config container-name” to display all of them together assuming container-name is defined at the top level of your YANG module.
If you would like to add a custom show output command to the CLI, you can refer to Chapter 19.22.6, Adding custom show output, in the ConfD User Command for information on how to do that.
I missed to mention that this config is not part of the configurational mode. This config is done in the operational mode through the input block of the action node.
Yes, the whole config is under a single container. Is there anyway to display the config without having to use list?
(can’t use list because the config doesn’t have any mandatory unique value)
Greg has already explained in the discussion thread that you have referenced the input attributes aren’t being stored in any datastore. There is no way for you to show the input values after you have executed an action statement.
You can only show what is stored in the datastores.
Since there is no way to store the config in any datastore, my application reads the config from the actionpoint and stores in a structure.
Now I want to implement a show command where I can fetch the config from the structure and display through a different container in the yang. Since none of the leaf nodes are mandatory, what would be the best way to achieve this?
Is there any reason why you can’t model the config data in YANG? Config changes made by the actionpoint will then be reflected in the config datastore. You will then be able to use the regular show command to display the config values.
there seem to be multiple contexts addressed here…
In the beginning, you mention list vs no keys -> this might correspond to presence container -> that can act as a single list entry with no mandatory keys (unrelated to whether you have config nodes or oper data (could be used for both cases)).
also, maybe it’s better to describe whole scenario/use case to clarify and make sure that you have correct tools to use
Linked thread uses an action… “action” by itself does not store any data, and can be invoked repeatedly to “perform some stuff” or provide some “output” parameters/values…
of course it can, as part of its work e.g. modify some configuration in confd by invoking own transaction etc.
You mentioned changing some “structure”… that is, i assume some app/program internal, that you can use then to provide data when needed. This data can be presented e.g. via config false YANG model with own simple data provider implemented…
To describe it in simple words, I have an internal C structure (a single record) that I want to display in a show command.
The C structure has fields like: vpn-id, src-ip, dest-ip, interface-name.
None of the fields in this structure is a mandatory field.
Should I try using a “presence” container in the yang and then register a exists_optional data callback? Is there any code reference to implement this?
Or, is there any other way to achieve this?
i see, thanks for clarification. In this case, container is just sort of sugar coat.
You can implement this as either action statement, or config false data.
If you use action statement, you can define all the data as output leaves, none of which will be mandatory. User then invokes action and gets none/some/all output leaves from your implementation as a result.
Other way is to implement it as config false data -> and them implement either data provider for on-request responses, or just send it to CDB oper datastore / delete it from CDB as necessary by the managing app that has internal data…
Whichever path you take, you can then use container as @waitai proposed above, or even presence container. For action, you even don’t have to use container at all, as all the optional leaves are wrapped by the managing action statement automatically.
config false vs action depends on specific data… whether you can imagine it belonging together with other operational state, or rather isolated event driven info (action).