save entire device config after service deployment

[ian.scheidler1]

Hi,

the customer would like to save the (entire) configs of the devices affected by a VPN service deployment to a FTP server for backup.

We see (on the devices) that at the end of pushing the configs to the devices NSO implicitly does a "write memory" on the devices it changed. But this behaviour lies outside the service logic. Is there a way to tell NSO to do e.g. a "write network" (to a specific FTP server) at that same moment?

Or can this only be achieved using ReactiveFastmap (i.e. doing sth. specific after the cb_create callback has executed, more precisely: after pushing the config(s) to the device(s) )?

The customer also has an Alias configured on the devices ("save") which already executes the appropriate command to save the config to a backup server. So this could be used too I guess.

Important is that the customer wants the "save to backup server" step done automatically after successful deployment of the service.

[gschudel]

This is an interesting question.
I've had several customers (as have others i'm sure) who wish to back up their full device configs periodically. What you're asking for seems to be mixing device and NSO operations. I don't see a device type listed - i.e. NED type - many have ned-settings to modify default behavior - the one you note is that "write-mem" is done at the completion of the service commit. E.g. for the cisco-ios NED (CLI) (see the README file...):

...<snip>...
- cisco-ios write memory-setting <enum>

This ned-setting is used to configure when/if an applied
configuration is saved to the device. Three values are supported:

on-commit - Save configuration immediately after the config has been
successfully applied on the device. If an error occurs when
saving the whole running config will be rolled back (default).

on-persist - Save configuration during the NED persist handler. Called
after the config has been successfully applied and commited
If an error occurs when saving an alarm will be triggered.
No rollback of the running config is done.

disabled - Disable saving the applied config to persistent memory.

- cisco-ios write memory-method <string>

This setting is used to change how the NED writes config to a
device. The default is "write memory".
...<snip>...

I have not tested the last one - not sure if this can assist you - i think it would "replace" the write-mem command and not be "in addition to it".... you would like to have both, correct?

** caution -- i think is worth noting: since the operation (ftp out to some server) may take time, it seems like this is not ideal to call from a service (due to the lock taken).

You don't mention how the service is executed; if it's coming out of a NB portal, you may simply call an action immediately after successful service deployment - where the action executed a live-status call to the device, creating a time-stamped file name etc. and doing the file transfer. This action could be triggered via a kicker as well. whether the "live-status" call specifies the exact command or an "alias" on the device is irrelevant - it could call any device command.

[Jan Lindblad]

If only the diff is needed, enabling device trace could do this. If a capturing a complete configuration is required, a subscriber app could do that. Note that the subscriber would be triggered to run inside the transaction lock, and if the configs are large, saving them within the lock would significantly reduce the number of transactions you could get executed in a given time. A kicker could be used to trigger the saving to happen outside the transaction, but this runs the risk of changes to a device happening while the save is in progress. If periodic backups of all the device configs are required, getting the full config from NSO at regular intervals might be a better option. This could be done using the backup-mechanism, or using e.g. get-config on /devices/device/config . They too take the lock, but since they would do that for all devices at once and only run at some interval chosen by the user, the performance impact is likely much lower.