Get Trigger when Netopeer completes copy-config successfull in an application where SYSREPO is present.

[Abrahamma97]

Hi @michalvasko I have an application, I want to do some operations in an application when user gives copy-config RPC in netopeer. So I want to know how we can connect, which session should we use and which event should we subscribe for the same.

[michalvasko]

Well, you can simply subscribe to the copy-config RPC but the callback will be called before the actual netopeer one so you will not be able to determine whether it is going to succeed or not. Not much else you can subscribe to.

[jktjkt]

I wonder why you need to subscribe to copy-config, though. In sysrepo, it makes sesne to think about it as a database, and to focus on changes of its content. It doesn't matter whether, say, the startup or running datastore was changed through edit-config, or through copy-config via NETCONF, or via a local console. What matters most of the time is that the new content of this DB is XYZ. You can already create subscribers for "changes of a datastore content", you can have one for startup, another one for running, and even one for operational if you want to be fancy. Note that you might need appropriate combination of flags such as SR_SUBSCR_ENABLED in order to truly get all events. Will this fit your use case by any chance?

[Abrahamma97]

Yes @michalvasko and @jktjkt if that is the case I can try connecting a startup session, see if there is any change in startup, check if SR_EV_DONE is there and if so I can do the operation. But how will we subscribe startup as a whole instead of just a module (as in sr_module_change_subscribe(session, "ietf-hardware", xpath, hw_module_change_cb, pvt_data, 0, 0, &subscription))

[jktjkt]

Sysrepo callbacks work on a per-module basis, so you get an event for module-1, another event for module-2, etc. What do you need this for?

[Abrahamma97]

As I need to see if any change has occurred in sysrepo startup config during copy config. @jktjkt will this be possible

[jktjkt]

@Abrahamma97 , this might be an example of the XY problem. I don't know yet what you need this for. Perhaps there's something in sysrepo which already fits your use case. Typically, the requirement is not "I want to know if a setting has changed during a copy"; more often it is something along the lines of "I need to save my hostname into /etc/hostname whenever the /ietf-system:system/hostname leaf changes in the startup DS", or perhaps "I want to dump my config to a persistent filesystem upon any change", or "I need this extra hook for validation", etc. So, what is the end goal that you hope to achieve?

[Abrahamma97]

Hi , Yes this is a clear case of "I want to dump my config to a persistent filesystem upon any change". So do you suggest a proper solution for the same and are you saying it is already implemented in sysrepo?

On Mon, 2 May 2022, 22:01 Jan Kundrát, @.***> wrote:

@Abrahamma97 https://github.com/Abrahamma97 , this might be an example of the XY problem https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem. I don't know yet what you need this for. Perhaps there's something in sysrepo which already fits your use case. Typically, the requirement is not "I want to know if a setting has changed during a copy"; more often it is something along the lines of "I need to save my hostname into /etc/hostname whenever the /ietf-system:system/hostname leaf changes in the startup DS", or perhaps "I want to dump my config to a persistent filesystem upon any change", or "I need this extra hook for validation", etc. So, what is the end goal that you hope to achieve?

— Reply to this email directly, view it on GitHub https://github.com/CESNET/netopeer2/issues/1205#issuecomment-1115098667, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANAZXOGJEFLBUXCA76HNGY3VH77ODANCNFSM5U3MWGSQ . You are receiving this because you were mentioned.Message ID: @.***>

[jktjkt]

If you're really "just" after persistency, then sysrepo actually does this out-of-box. If your /etc/sysrepo is persistent and if you "somehow" handle updates (or are sufficiently careful about them), YANG module installation, and what not, you're already done. Your startup config is already saved on disk, and after reboot you'll get its content just fine.

In the real world, though, it's not all roses. Some rather common scenarios (such as a read-only rootfs, or a generic rootfs image for different configurations of YANG modules, or anything real-world with long-term support considerations, possibly incompatible YANG module updates -- and we've been there with sysrepo itself -- etc) require a bigger hammer. You can take a look at how we're implementing this for our DWDM whiteboxes. I've described our setup a few times on GitHub already:

• https://github.com/sysrepo/sysrepo/issues/2726
• https://github.com/sysrepo/sysrepo/issues/2280

[Abrahamma97]

@jktjkt I got confused by looking at the thread. Could you help me out here. Are you saying we have to make changes in the build itself and not during run time. Can you summarise the same?

If your /etc/sysrepo is persistent and if you "somehow" handle updates (or are sufficiently careful about them), YANG module installation, and what not, you're already done. Your startup config is already saved on disk, and after reboot you'll get its content just fine.

Yes I want to get notified when startuo config is changed and I want to copy the same file to another sysrepo which is independent of the same. So that we get the same startup config on both sides.

[jktjkt]

I don't understand your question. What have you tried, what are the results, and what end result do you hope to achieve?

[Abrahamma97]

Hi your solution if I understand correctly is to enable this service which creates the backup startup.json file right (see below reference)?

sysrepo-persistent-cfg.service

[Unit] Description=Persisting persistent sysrepo datastores to /cfg After=netopeer2.service cfg.mount Requires=netopeer2.service cfg.mount

[Service] Type=simple UMask=0077 ExecStart=/bin/sh -c 'while true; do inotifywait -e CLOSE_WRITE /etc/sysrepo/data/*.startup && mkdir -p /cfg/sysrepo/ && sysrepocfg -d startup -f json -X > /cfg/sysrepo/startup.json; done'

This is what you meant right??