I’m not sure if I got correctly what the ratio is with the implementation of NETCONF in Confd. What I understood is that when a configuration is received, this is first validated using the YANG model, it is then written on the CDB (if valid) and only then it is handled via a subscription to the CDB.
In my case my configuration can contain a route to be added to a routing table.
I would add the route using my Python script, that has a subscription to the DB.
Is it possible, in case there is some error while adding the route, to make the DB roll back to the previous configuration? Plus, the transaction should not be acknowledged to the NETCONF client (I’m using NSO).
From what I saw, the Python subscription can only read configuration data and I cannot (?) use it for aborting the transaction when I have some error (even though there is the possibility to apply a lock to the DB while processing changes, I guess that is only to make sure the data is consistent during all my processing).
If I want to make some operation before the transaction is accepted I can use custom scripting using validation points in the YANG model. That would probably work, but it is not the intended use I guess? (that should only be intended for semantic validation).
Finally, are validation points the only way of executing some custom code before a transaction is validated or can I do it after the DB has been written a first time and then eventually roll back?
This is not the recommended, as you will cause the NETCONF client (e,g, manager / service provider) to become out of sync with the your NETCONF server.
Now the NETCONF client need to sync the configuration back to not only its representation of your node, but also the service where not only your node is configured as part of a service deployment.
The sync back all the way to the service configuration is often the tricky part and so you want to avoid spontaneous node reconfigurations at all times.
So instead of changing the NETCONF client “intended” configuration in CDB running using MAAPI and a transaction hook, you want to update the “operational-state” representation of the configuration using the CDB API and the CDB operational datastore or through providing a callpoint.
There are two ways of implementing “intended” configuration and “operational-state”, either you use
a separate “intended config data” (config true) plus a “operational state data” (config false) representation in the YANG model. See the IETF routing YANG model RFC 8022 Appendix A for an example overview.
or you use NMDA (ConfD 7.3 or later) where there is no need for a “config false” copy of the “config true” YANG parts that can have both an “intended” config set by the NETCONF client and an “operational state” that is set by the application. See the IETF routing YANG model RFC 8349 Appendix A for an overview of the NMDA version.
So using either of the above approaches, your Python script would only update the “operational state” and not the “intended configuration” that the NETCONF client (manager / service provider) update.
See
examples.confd/intro/python/13-stats_push for an example where the operational state data is set in the CDB operatoinal datastore
examples.confd/intro/python/5-stats for an example where the operational state data is provided via a callpoint.
ConfD 7.3 examples.confd/nmda for an NMDA python example
See two phase subscription in ConfD User guide (confd_lib_cdb). The subscription can run in two phases. In first phase you can perform configuration of the device, if something goes wrong, you can still abort transaction. You must be able to revert already applied configuration on the device(s). Also all other two phase subscribers, that already successfully applied configuration, have to revert configuration in second phase. This may not be possible for some types of devices. See int cdb_subscribe2, enum cdb_sub_type, int cdb_read_subscription_socket2.
Thank you for your answer, it already made me proceed a bit. I have now another problem, it is not clear to me how exactly I am to use NMDA inside ConfD.
Since it has only been added with the last update in the end of last month, maybe some features are still not fully implemented.
My problem is that I can’t seem to find a way to update the operational datastore. If I use MAAPI it tells me that the element is not writable, when I’m using CDB API the element does not even appear inside the operational datastore.
I am using a YANG model that does not contain any “config false” copy of the tree, since with NMDA it should not be needed.
Now I don’t know whether I should somehow tell ConfD that I’m using this kind of implementation and I that should be able to modify the data inside operational.
I would do this operation independently from the subscriber I use with the configuration running datastore, but there shouldn’t be locks on the database that prevent me from doing that.
I could try to use callpoints, but in my case I would prefer to write my state data in the CDB (at least the one that describes the routes I have in the router).
Unfortunately it looks like they didn’t release such example with the last version of ConfD…
Hmm, as you describe, there doesn’t seem to be a way to load “config true” data over MAAPI or the CDB API into the CDB operational datastore to present it as operational-state only.
I will check if this is a known issue.
Storing “config true” data in the ConfD operational datastore to present it as operational-state data is not possible yet. It will likely be supported in a future ConfD release.
So for now, you need to use tailf:callpoint’s with tailf:operational and a data provider application to present “config true” data as operational-state data.