ZTP High Level Design #281
Conversation
| 10. ZTP service will enable updategraph | ||
| 11. ZTP service will call for reboot to apply new SONIC image, with option ZTP-enabled –post_install | ||
| 12. Upon reboot, if ZTP service flag $post_install is true, ZTP hands off to updategraph | ||
| 13. The configuration script is received and applied by updategraph, returns to ZTP service |
There was a problem hiding this comment.
updategraph seems very minigraph like in name, what is the config file being downloaded? a shell script? a minigraph.xml file? a config.json file?
There was a problem hiding this comment.
Historically updategraph was used to deploy minigraph.xml files but moving forward SONiC configuration will be done using a config.json file.
There was a problem hiding this comment.
Would it be possible to consider loading a shell script and executing it rather than a config.json? Reason is the following: with FRR the config no longer lives in config.json but in a separate frr.conf file, same with snmp config. Having a bash script allows the operator to have more control over the ZTP process and be creative rather than being forced into a static model. The shell script could replace j2 templates for eg. perform certain daemon reloads etc.
I do understand that with the config checking and reporting that happens later in the process a minimal config can be loaded then an external agent could come in and finish the full device commissioning .
There was a problem hiding this comment.
Thank you for your input Michel. The tentative agenda for the next community meeting is on ZTP, we can bring up this point then and see what the community says
doc/ztp/ztp_hld.md
Outdated
| - ZTP service flag $post_config is false | ||
| 3. The switch now enters ZTP mode and does the following, | ||
| - Obtains an IP address from the DHCP server | ||
| - Obtains the URL for the SONIC image, provisioning script, and post config validation script |
There was a problem hiding this comment.
please define "provisioning script", "post config validation script", unclear.
There was a problem hiding this comment.
Updated the doc with description of these items.
doc/ztp/ztp_hld.md
Outdated
| 3. The switch now enters ZTP mode and does the following, | ||
| - Obtains an IP address from the DHCP server | ||
| - Obtains the URL for the SONIC image, provisioning script, and post config validation script | ||
| 4. At this step, the switch will have information to reach the HTTP / TFTP server information by DHCP option 66 or Option 240. |
There was a problem hiding this comment.
what is option 66 or option 240. What information are you referring to. please make it clear.
There was a problem hiding this comment.
these are private options for DHCP
doc/ztp/ztp_hld.md
Outdated
| - Obtains an IP address from the DHCP server | ||
| - Obtains the URL for the SONIC image, provisioning script, and post config validation script | ||
| 4. At this step, the switch will have information to reach the HTTP / TFTP server information by DHCP option 66 or Option 240. | ||
| 5. ZTP service will relay to updategraph service |
There was a problem hiding this comment.
please define relay, what do you mean by relay.
There was a problem hiding this comment.
updated the wording in the new doc
doc/ztp/ztp_hld.md
Outdated
| - Updategraph handles all configuration during ZTP service | ||
| - ZTP should receive post config validation script, that collects switch info and sends it back to a remote location for processing | ||
| - ZTP status may be logged through syslog | ||
| - Interruption of ZTP service should disable the service gracefully |
There was a problem hiding this comment.
please clarify this requirement
There was a problem hiding this comment.
clarified in the document. If ZTP service is interrupted at any stage, status of ZTP should be "aborted" with explanation of what point ZTP was stopped at.
| - Set $enable to false | ||
| - Verify no errors were thrown during the service | ||
| - Output to syslog server and var/log/syslog | ||
|
|
There was a problem hiding this comment.
please clearly define the dhcp option ztp is going to send to server, and dhcp option ztp is going to receive from server and use.
There was a problem hiding this comment.
Updated within document changes.
There was a problem hiding this comment.
Guohan, I've added a table in the document that specifies the private DHCP options given/received
doc/ztp/ztp_hld.md
Outdated
| Need to allow build time option to compile with ZTP enabled | ||
|
|
||
| # Error Cases | ||
| - Case: Switch receives invalid URLs from DHCP server |
|
Simone, how does ZTP process can handle situations like devices are continuously reloading after ZTP workflow? |
|
|
||
| # Requirements | ||
| - Build option to have ZTP enabled | ||
| - SNMP should be enabled during the ZTP process (achieved through leveraging updategraph) |
There was a problem hiding this comment.
Please explain why SNMP is important to this process - it's not clear to me where it's used here.
| @@ -0,0 +1,166 @@ | |||
| # Zero Touch Provisioning (ZTP) | |||
There was a problem hiding this comment.
Generally, I think many user ZTP flows will start from ONIE, not from a pre-installed SONiC image. I think this should be discussed a little. For instance, in an ONIE flow, the run-time image is usually installed by the ONIE installer, and not by the SONiC ZTP. So, in this flow, I think a ztp_image_url should be treated as optional, and lack of a valid one should not be treated as an error.
| |:-----------:|:-------------------|:-------------------------------------------------| | ||
| | 224 | snmp_community | usage implemented through updategraph | | ||
| | 225 | minigraph_url | usage implemented through updategraph | | ||
| | 226 | acl_url | usage implemented through updategraph | |
There was a problem hiding this comment.
Why are the snmp_community and acl_url broken out as separate options? Could they not be done as part of the minigraph_url delivered config?
| | 225 | minigraph_url | usage implemented through updategraph | | ||
| | 226 | acl_url | usage implemented through updategraph | | ||
| | 227 | ztp_image_url | URL for the SONiC image for the switch to dowload | | ||
| | 228 | validation_url | URL for the validation script -- a script that runs post config and collects device info and sends it for processing to a remote location designated within the validation script | |
There was a problem hiding this comment.
I think we should change the name of this to "post_install_url" - there is no need to limit this to validation - it could do anything that the user chooses.
| 4. At this step, the switch will have information to reach the HTTP / TFTP server through URLs given by DHCP server. | ||
| 5. ZTP service will enable and start updategraph service | ||
| - Within updategraph, ztp_enabled is true, and post_install is false | ||
| - This triggers updategraph to configure the device with an default config |
There was a problem hiding this comment.
Please explain where the default config comes from? Where does updategraph get this from, and how is this put into the build?
| 9. ZTP service will install image using sonic-installer | ||
| - ZTP service flag $post_install is true | ||
| 10. ZTP service will enable updategraph | ||
| 11. ZTP service will call for reboot to apply new SONIC image, with option ZTP-enabled –post_install |
There was a problem hiding this comment.
Can we avoid this re-boot? It doesn't seem necessary, especially in cases where the image install happens in ONIE.
| # ZTP CLI | ||
| The ZTP CLI will allow the user to manually start, stop, and obtain status of the ZTP service. | ||
|
|
||
| Will show the user whether ZTD is enabled, the date of the last execution of the ZTP script, and the completion status of the ZTP service |
| The ZTP status will show the user the current SONiC image, if the configuration was successful, and if the post-configuration script was run, as well as the time of the last successful completion of the ZTP service | ||
|
|
||
| config ztp enable | ||
| The user can re-enable ZTP after a failed state using the CLI. This puts the switch into “factory setting” and reloads with ZTP enabled, allowing for provisioning restart. |
There was a problem hiding this comment.
This is a nit (so feel free to ignore!), but is this usage really limited to failure cases? Are there not cases where the user wants to re-run ZTP for other reasons (e.g. re-do a configuration)?
| - ZTP is enabled and post_install is true, apply configurations using updategraph | ||
| - Run post_validation script | ||
| - Exit ZTP | ||
| - Test to see if Ansible server is reachable for further configuration |
There was a problem hiding this comment.
Why is this here? Seems like it's outside the scope of ZTP (already exited).
| ### Build Option | ||
| Need to allow build time option to compile with ZTP enabled | ||
|
|
||
| # Error Cases |
There was a problem hiding this comment.
Should probably add some cases for network events, such as: -
- DHCP server does not respond
- URL targets not reachable, or lost connection during load
- etc
yxieca
force-pushed
the
master
branch
2 times, most recently
from
8498931 to
8837dc2
Compare
Introducing ZTP HLD for SONiC