Whatever I try, I am unable to update vyos using ansible. Here is my playbook:
---
- hosts: all
gather_facts: no
vars:
ansible_connection: ansible.netcommon.network_cli
ansible_network_os: vyos.vyos.vyos
tasks:
- name: add system image
vyos.vyos.vyos_command:
commands:
- command: "add system image http://files.server.com/VyOS/vyos-1.3.4-amd64.iso"
prompt:
- "What would you like to name this image"
- "directory and config file"
- "current configuration"
answer:
- "1.3.4"
- "Yes"
- "Yes"
check_all: True
vars:
ansible_command_timeout: 180
this fails with
FAILED! => {“changed”: false, “msg”: “command timeout triggered, timeout value is 180 secs.\nSee the timeout setting options in the Network Debug and Troubleshooting Guide.”}
I couldn’t replicate it in VyOS 1.3.3 or 1.4.* using your playbook. Are you certain it’s caused by the progressbar? It could be that the image takes nearly three minutes to download and the miniscule difference in I/O speed is pushing it over the timeout limit: Without the need for a progress check, the download script uses shutil.copyfileobj() which is fairly fast, but otherwise it needs to manually handle the session to download in chunks to report on the progress, which adds a bit of overhead.
Edit: For posterity, I tried it with 1.5-rolling too, which uses a more complicated progressbar implementation with signal handlers and termcap fiddling that was more likely to break Ansible, but it seems to work without a problem as well.
To be more specific for the record, Ansible’s core modules (correctly) fail the isatty() check but ansible.netcommon.network_cli seems to pretend to be an interactive shell (presumably to make sure programs run in interactive mode where prompts can be automatically answered), so I put a special case for the $TERM envvar it sets (vt100, which pretty much nobody uses today outside barebones emulation through automated tools like this, not too far off from dumb, unknown and vanilla as defined in terminfo). I hope this works for you.
I brought up the idea to pass specific parameters to CLI for this kind of automation to the team. Normally only source port, source address, username and password can be set. At the very least we’d like to provide this kind of flexibility to the HTTPS API. I’ll be sure to mention it in a monthly progress announcement when we come up with a solution.
I’ve just encountered this issue on multiple builds of 1.5 rolling, with the earliest being from May 2024, the most recent one from mid October 2024. Using ansible_persistent_log_messages I was able to track it down to the progressbar flooding the logs, just as @professional_prutser described and showed in his pastebin snippet. Is this a regression in the code, or could it be Ansible is taking a different approach to communicate with the host, causing the fix to fail? We’re on Ansible 2.17.1.
@Erkin any chance you could have a look at this? As I was unable to find other reports about this issue since this was supposedly fixed, it could be a local only issue as well. Allthough very strange, as we’re not doing anything special with Ansible either.
For anyone else with this issue, just prefix the actual command in the cli_command command: with TERM=dumb && to force toggle the VyOS shell into the “dumb” mode the patch mentioned above introduced.
I still don’t know if the patch was meant to be auto enabled, i.e. detect whenever something like Ansible connects or if it is supposed to get triggered manually by doing what I do now. This should be clarified somewhere in the documentation. Seeing the Ansible VyOS role being taken over by VyOS maintainers, that could be a good place to put such information.