How to download EOS from a script

Hi Francois,

Yes you can! Check out the eos_download.py from https://github.com/arista-netdevops-community/eos-scripts
Your SE team will also follow up with you on your project.

Thanks,
Tamas

Thank you for updating us with the outcome.

outcome is that it works quite well, but not end to end yet.

• a script runs every morning. I use 2 image bundles in CVP, EOS-latest, that is applied on a subset of non critical switches, and EOS-stable, applied on all the other ones.
• I rely on https://www.arista.com/en/support/release-notes to probe for new versions. This Atom feed is not necessarily up-to-date (it's missing 4.25.5.1M as I write this)
• eos_download works by downloading a piece of xml that contains all the deliverables, it works as long as the format of the xml file stays the same (it changed once in the past)
• cvprac python module works fine to upload the EOS image/TerminAttr to CVP into the EOS-latest image bundle. The script additionally, verify that there is no alert on the stack and no pending task to execute. I do that through a call to a Prometheus API, that will check for any alert, and in fact we still have one remaining alert today that prevent us to go forward. For example a network interface down on a server will trigger an alert, and we won't upgrade any switch in that case.
• once the EOS image is uploaded and part of the EOS-latest bundle, tasks are created automatically in CVP. To actually trigger the execution of the tasks we need to create a change control in CVP, which needs a little bit of coding due to https://github.com/aristanetworks/cvprac/issues/132

So providing the new TerminAttr/EOS releases are properly part of the RSS feed, I wake up in the morning with tasks waiting for me to execute in CVP. For CVP itself I'm doing everything by hand so far (call to eos_download + triggering the install), same for major upgrade (eg: EOS 4.26). For EOS-stable I am still changing the bundle and executing tasks by hand (the image is already uploaded on CVP)

The outcome is our system is kept up-to-date without much effort. We did have a few challenges: some switches refused to ugprade from time to time (CVP triggers a curl on the switch that will download the image from CVP, and the curl is not using the proper Loopback interface), and we have 3 servers that send their traffic through their 1G interface instead of their bond, so we have 3 switches we don't know how to upgrade without impact. One thing we had to do is to increase some timeouts so that we don't get alerts every time we upgrade.