Add system image http with ansible

Bugs
,
1

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.”}

However, if I remove the fancy progress bar (âš“ T4091 Progress bar support for HTTP uploads)

adm@vyos:~$ sudo sed -i 's/download(local_path, urlstring, True/download(local_path, urlstring, False/' /usr/lib/python3/dist-packages/vyos/remote.py

the playbook works just fine.

Could someone verify this? What else should I test before reporting a bug? Let me know!

  • ansible [core 2.15.6]
  • VyOS 1.3.2 LTS
  • Python 3.11.2
2

using ansible.netcommon.cli_command with ansible_persistent_log_messages gave me some insight on wat happens:

My guess is the ammount of “\r” (return caracters) is the culprit.

3

Thanks for pointing this out. I’ll add an isatty() check and forcibly disable progressbar output accordingly.

5

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.

6

isatty() check

If we just could pass all the arguments with the system add command instead of pompts… That would be a lot easier for Ansible i think.

Are you certain it’s caused by the progressbar

well I am not a python programmer, but that is the only thing the sed command changes, right?

It could be that the image takes nearly three minutes to download

The url points to another server in my own (public ip) network. It takes seconds with 10Gbps.

7

Does Ansible report anything else in terms of logs? Anything that sticks out when you run the playbook with -vvvv?

8

This similar bug for the API âš“ T5726 HTTPS API image cannot be updated

9

@professional_prutser Although I couldn’t replicate the problem with the Ansible VyOS module on any version, I still think the progressbar is a nuisance as it litters logs if nothing else. I pushed a PR that disables it if it detects it is called by Ansible and it was backported to 1.4.

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.

1 Like
10

Looks like the PR is already merged. Thanx @Erkin for your work.