Potential facts issue in 6.0.0 collection for VyOS 1.4.3
Closed, ResolvedPublicBUG
Actions

Assigned To

Authored By

	evgmol
	Aug 7 2025, 9:26 PM

Description

We have one issue. 3 VyOS system. The same configuration, the same version 1.4.3. After running a playbook, the following error appears on two routers. One works well.

fatal: [XXXXX]: FAILED! => {
    "ansible_facts": {},
    "changed": false,
    "failed_modules": {
        "vyos.vyos.vyos_facts": {
            "exception": "  File \"/tmp/ansible_vyos.vyos.vyos_facts_payload_233xrwlu/ansible_vyos.vyos.vyos_facts_payload.zip/ansible_collections/ansible/netcommon/plugins/module_utils/network/common/network.py\", line 218, in get_capabilities\n    capabilities = Connection(module._socket_path).get_capabilities()\n                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/tmp/ansible_vyos.vyos.vyos_facts_payload_233xrwlu/ansible_vyos.vyos.vyos_facts_payload.zip/ansible/module_utils/connection.py\", line 199, in __rpc__\n    raise ConnectionError(to_text(msg, errors='surrogate_then_replace'), code=code)\n",
            "failed": true,
            "invocation": {
                "module_args": {
                    "available_network_resources": false,
                    "gather_network_resources": null,
                    "gather_subset": [
                        "min"
                    ]
                }
            },
            "msg": "show version\r\n\r\n  Invalid command: [show]\r\n\r\nansible_adm@router:~$ "
        }
    },
    "msg": "The following modules failed to execute: vyos.vyos.vyos_facts\n"
}

We can not reproduce it in our lab.

Details

Version: 6.0.0
Is it a breaking change?: Unspecified (possibly destroys the router)
Issue type: Bug (incorrect behavior)

Event Timeline

evgmol created this task.Aug 7 2025, 9:26 PM

@a.apostoliuk hi!
Can we have:

Playbook for the testing (or description of attempted operations) OR Traces from the playbook run in the verbose mode (ansible-playbook <playbook_file.yaml> -vvvv)
show version Output on the routers
Output of ansible-galaxy collection list |grep netcommon in the client environment -

thank you!

Additional details from Slack:
it is not only 1st run. He runs his playbook for 3 routers. Only one works without problems. He says that the configs are the same and the version is - 1.4.3.
Ansible verbose info

ansible-playbook [core 2.17.13]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/ansible_adm/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  ansible collection location = /home/ansible_adm/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible-playbook
  python version = 3.11.2 (main, Apr 28 2025, 14:11:48) [GCC 12.2.0] (/usr/bin/python3)
  jinja version = 3.1.2
  libyaml = True

He uses 6.0.0 vyos ansible collection.

pasik subscribed.Aug 8 2025, 11:49 AM

Playbook:

---
# FUNCIONAL

- name: BackUp Cuideo router's config
  hosts: CUIDEO_ROUTERS
  
  tasks:
  - name: Collect facts
    vyos.vyos.vyos_facts:
      gather_subset: all

  - name: Create backup dir
    file:
      path: "/home/ansible_adm/backups/CUIDEO/{{ inventory_hostname }}"
      state: directory
      recurse: yes

  - name: Backup
    vyos.vyos.vyos_config:
      backup: yes
      backup_options:
        dir_path: "/home/ansible_adm/backups/CUIDEO/{{ inventory_hostname  }}"

- name: Delete Old BackUp Files
  hosts: localhost:CUIDEO_ROUTERS
  vars:
    backup_dir: "/home/ansible_adm/backups/CUIDEO/{{ inventory_hostname  }}"
    backup_keep: 10
    dry_run: false

  tasks:
    - find:
        path: "{{ backup_dir }}"
      register: result
    - set_fact:
        files_rm: "{{ (result.files|
                      sort(attribute='mtime', reverse=true)|
                      map(attribute='path')|
                      list)[backup_keep:] }}"
    - debug:
        var: files_rm
    - file:
        state: absent
        path: "{{ item }}"
      loop: "{{ files_rm }}"
      when: not dry_run|bool

...

$ ansible-galaxy collection list | grep -E "vyos.vyos|ansible.netcommon"
ansible.netcommon                        6.1.3
vyos.vyos                                6.0.0

evgmol claimed this task.Aug 15 2025, 10:10 AM

More in Slack https://vyos-community.slack.com/archives/C027BSYGHPT/p1754577533265449
In general:

The entire things is about SSH being unable to enter the CLI mode - so the commands are send in 'raw' SSH mode, and VyOS needs CLI
Might be different things - i.e. custom port 7222/tcp (so if you client can try and login to the system ssh vyos@target_ip -p 7222, and then run show version command - I'd be keen to see the result)
In my case I managed to break the system by corrupting /home/vyos/.bashrc, which is responsible for running CLI for non-login shells

I suggest your client to review their remote target environment setup, maybe by comparing healthy and faulty systems, and playing with ssh I will be here to help if new details are available

evgmol changed the task status from Open to In progress.Aug 20 2025, 3:25 AM

evgmol triaged this task as Normal priority.

evgmol closed this task as Resolved.Mon, Nov 10, 7:43 PM

Potential facts issue in 6.0.0 collection for VyOS 1.4.3Closed, ResolvedPublicBUGActions

Description

Details

Event Timeline

Potential facts issue in 6.0.0 collection for VyOS 1.4.3
Closed, ResolvedPublicBUG
Actions