Is it possible to use "commit dry-run" but have it produce a complete configuration of the device?

[Scott.ODonnell@gmail.com]

I'm working through a scenario where I'd like to "commit dry-run" a service but instead of getting back only the changes, I'd like to get back the entire modified configuration.

Is there a process that would allow for this?

[Jan Lindblad]

Commit dry-run cannot do exactly this on its own. You are not describing your use case; why would anyone need something like this? If you do, there may be some alternate paths to satisfy your use case.

a) Your service code has access to the entire device config, so at the end of create, it could rather easily produce some sort of output that you are interested in.

b) If you don't want to modify some existing service, you could make a wrapper service that does this.

c) If this isn't a service, just device configs, you can simply show whatever you want (and pipe to a file, if you like) on the device level

d) You could commit no-networking, show all the things you are interested in, then rollback configuration, commit no-networking again. This is a bit hacky, I know.

[Scott.ODonnell@gmail.com]

Jan, 

Thank for the feedback.

My use case is as follows:

- Within the service create code, execute a dry-run (or some equivalent ) and end up with a fully modified set if configs for the devices in question.

- Package the fully modified configs and feed them into a network modelling platform which will evaluate the new configuration changes (along with the rest of the unchanged network model) and predict what impact the modified configs will have to the overall network behaviour.

- The result of the call to the modelling platform will be a binary pass/fail condition that will update a boolean "leaf" value in the service model.

- I think I will have to leverage a kicker to have the service model initially execute, package up the dry-run information and send it to the modeling platform.

- Once the modeling platform evaluates the changes, it will update the service vars to indicate pass/fail and my plan is to use that update to trigger a kicker for the service to "continue" ( I think this would be reactive Fastmap) or abort.

I'm working in python and I'm picking through the objects in root.devices.device looking for a way to retrieve a full-text representation of the config after the dry-run commit has happened but I haven't found it yet.

In your response, you mention in option a.) I could produce some sort of output that represents the config with dry-run changes. If you could expand on that, I would appreciate it.

I suppose it would be possible within my service create code to pass the entire service model to some glue code that pulls the related device information from the production NSO/CDB and then recreates it in another "Sandbox" NSO system where it could do the commit, retrieve the entire config, then model everything. Once complete, the glue code would just delete the information from the sandbox NSO.

[Jan Lindblad]

My use case is as follows:

- Within the service create code, execute a dry-run (or some equivalent ) and end up with a fully modified set if configs for the devices in question.

- Package the fully modified configs and feed them into a network modelling platform which will evaluate the new configuration changes (along with the rest of the unchanged network model) and predict what impact the modified configs will have to the overall network behaviour.

I suppose this will take a little while, i.e. longer than a couple of seconds? If so, you probably want an RFM solution.

- The result of the call to the modelling platform will be a binary pass/fail condition that will update a boolean "leaf" value in the service model.

- I think I will have to leverage a kicker to have the service model initially execute, package up the dry-run information and send it to the modeling platform.

Yes, a config false boolean leaf "validated-by-external-tool" could be used here, plus a re-deploy. The re-deploy could come from a kicker or something entirely else, e.g. the external tool itself or a script that runs the external tool.

- Once the modeling platform evaluates the changes, it will update the service vars to indicate pass/fail and my plan is to use that update to trigger a kicker for the service to "continue" ( I think this would be reactive Fastmap) or abort.

Yes, the tool or script that launches the tool could write the config false boolean flag as true or false when the verdict is ready, and then redeploy the service instance. Or a kicker can do the last part. Yes, this is a Reactive Fastmap RFM design.

I'm working in python and I'm picking through the objects in root.devices.device looking for a way to retrieve a full-text representation of the config after the dry-run commit has happened but I haven't found it yet.

In your response, you mention in option a.) I could produce some sort of output that represents the config with dry-run changes. If you could expand on that, I would appreciate it.

To produce a textual representation, I suggest looking into the _maapi function
save_config(sock, thandle, flags, path) -> int   and friends.

They can produce CLI text output for your (device) config.

You can find a Python example of how to use save_config in:

https://github.com/NSO-developer/pioneer/blob/master/python/pioneer/op/config_op.py

[rhinst001]

I don't think there are any options to do that with just a commit dry-run, but I think you could just do a "commit no-networking", then pull the full device config from CDB, and then rollback the commit.  Hope that helps.

[rhinst001]

Oops. Somehow I didn't notice that Jan had already answered this before me. Sorry for the redundant answer.