Working with ZTP Scripts
Basic Info
Simulation instances have a ztp_script property which accesses any ZTPScript associated with the simulation.
A ZTPScript holds one entry per configured OS type in ztp_configs: cumulus is the provisioning script and nvos the ZTP JSON object. content is the Cumulus script, or None when only NVOS is configured.
Adding ZTP Scripts during Import
Adding ZTP Scripts after Creation
Updating ZTP Script Content
Configuring ZTP Per Os Type
A simulation can carry a Cumulus script, an NVOS ZTP configuration, or both. Updates change only the OS types they are given, each replaced whole (nothing is merged inside an OS type’s configuration), and remove an OS type set to None; removing the last one needs delete_ztp_script(). Changes need the simulation to be INACTIVE. These cells need an Air release with per-OS ZTP support.
Saving doesn’t provision anything by itself: Air serves the configuration from the simulation’s OOB server, so the simulation needs automatic OOB with DHCP (enable_auto_oob(), DHCP on by default). The OOB server rebuilds its ZTP files each time the simulation starts, and a switch gets the change the next time it runs ZTP, as on a clean start (start(checkpoint=None)). A switch restored from a checkpoint resumes from its snapshot and may not run ZTP again.