how to fill running datastore with transapi_init()?

[lofflermic...@gmail.com]

Hello,

Could you help me guys please?
I would like to know what is the correct way to initialize transAPI plugin correctly with transapi_init(xmlDocPtr *running) - specifically, when I need to modify(create) XML datastore content.
Currently, I have in transapi_init some code which creates and fills XML doc with all necessary nodes for my model, and puts it in *running pointer. But after calling transapi_init() on server startup, no changes are made to the running datastore at all.
In server logs I can see that transapi is calling callbacks with REM operations, which probably means that my newly created configuration in *running is being removed immediately.
Should I write such callbacks for those REM operations, which would only copy old_node to new_node, so the removed config would actually stay undeleted? (old_node - my created startup config, which is being deleted automatically).

(I have read this similar topic: https://groups.google.com/forum/#!topic/netopeer/z2fm7t3L0Po , but at the end I couldn't understand clearly what to do)

Or let's assume some simple example: a Yang model of a directory, which has list of files in it (it can be list of strings=filenames).
When starting the plugin, in transapi_init() it should read directory content (for simplicity, directory path can be hard-coded) and write it into running datastore. (I'm only using running datastore). In this case, what exactly would you do to make it work, please?

Best regards,
Michal

[Michal Vasko]

Hi Michal,

this is how it works. There are three datastores in Netopeer, running, startup and candidate, we don't care about the last one now. Let's say a transAPI module is being initialized. You start with the running config (presumably reflecting the current state of the system, if nothing changed since terminating the server). Then you are given the chance to check whether this really is the case, if there weren't some changes, in transapi_init() function. There you're supposed to detect the current state of the system and build the corresponding XML configuration. After that libnetconf considers the running configuration to match the one on the device. So, it finally copies the startup configuration to the running and calls the appropriate callbacks. This way it should be possible to fully control the module start and not call callbacks on invalid changes. I hope this made it clear for you.

Regards,
Michal