The short answer: there are two options.
Option 1 - Southbound lock, outformat native
Create one or more device templates and/or services that model the day 0/day 1 config that you need. Create the new device (with the right capabilities - see below), and southbound lock it. Apply your services, and then "commit outformat native" to generate the full configuration, in native output, for the device.
Pros: All NSO template/service logic can be used - multiple complex services can be deployed to the device before generating config.
Cons: Code required to process outformat native. See below.
Cons: Pre-NSO 4.4: This also required the use of a NetSim device. See below.
Option 2 - Text templates
ESC, vMS-PnP, and some Advanced Services projects use one or more parameterised plain text file for day-0 configuration. This is then populated with a simple search/replace operation in your code.
This can then be stored either on the NSO file system in the webserver - accessible via URL, or as an operational data field on your service - accessible via the NBI's.
Pros: Allows config options that are not supported by the NEDs. Allows comments in config for CLI engineers. No special post processing code.
Cons: Potentially duplicates the template maintenance work.
Post Day 0/1:
If Services were used to generate the configuration, when the device is added to NSO, it might be required to perform some reconciliation for any services applied, so that Fastmap works correctly for day0/1 modifications.
Notes on Option 1:
Capabilities:
Since NSO 4.2 (approx) the Device Manager and some NEDs slightly vary their behavior depending on the model and capabilities of the end device. NSO models that in device capabilities.
Pre-4.4, it was required to use a NetSim device, to allow NSO to get some capabilities set. Since 4.4, it's possible to clone or set capabilities, so no need for a NetSim device.
Defaults:
The Device Manager and NEDs understand the concept of default settings. However, some older Cisco devices have different default values than newer ones. This is taken care of in the Device Manager and NED when they access the device. But in the case of generating a configuration file, it might be required to explicitly include the defaults. This is possible:
commit dry-run outformat native | display details
outformat native Post Processing:
outformat native outputs some additional characters that need to be removed:
- diff prefix's (+,-, etc. As this is expected to be a clean device, there should be no -'s)
- spaces
- there are some initial settings that are often set in day0 config, such as VTY settings, that a NED normally deals with when it connects, before it sends other commands, that may need to be included in the day 0 config.
