@sbarvick , the problem here is that the python scripts are not implemented with yang-modeled data. Can we still integrate with netconf without making any yang changes. Let me know your thoughts on this.
NETCONF runs from the YANG-modeled CDB data. It is not clear to me how your CLI commands are implemented or what data they use if they don’t run from the YANG-modeled data so it sounds like the first step is to make sure the YANG-modeled data is what you want it to be, giving you the NETCONF you would like, and then adjust the CLI commands accordingly. It looks like your CLI commands are close to the YANGs that you would like to use so you should perhaps try to not use custom CLI commands and just use what is auto-generated by ConfD.
Or, to rephrase → to have NETCONF features provided by ConfD on a data set, you need YANG model for this data.
You can theoretically:
-
create new YANG model if you need to keep old one untouched
-
if you need only read access → make this new YANG’s nodes
config false; tailf:callpoint ...;and implement confd-lib data provider. Inside of its code, retrieve/prepare data using same process/source as in your current custom CLI commands… -
if you need write access as well make it a transformed model (
tailf:callpoint ...{ tailf:transform true; }) , and implement read/write callbacks in same manner as in previous variant -
export new YANG model to NETCONF only (compile YANG to FXS with specific
--exportonly), so it does not pollute your other APIs