[Bug]: API calls don't follow HTTP redirects.

[CompPhy]

Ansible NetBox Collection version

v3.19.1

Ansible version

ansible [core 2.17.2]
  config file = /home/kshutt/projects/iaas/ansible.cfg
  configured module search path = ['/home/kshutt/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/kshutt/venv311/lib64/python3.11/site-packages/ansible
  ansible collection location = /home/kshutt/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/kshutt/venv311/bin/ansible
  python version = 3.11.7 (main, Jan 26 2024, 19:22:20) [GCC 8.5.0 20210514 (Red Hat 8.5.0-21)] (/home/kshutt/venv311/bin/python3.11)
  jinja version = 3.1.4
  libyaml = True

NetBox version

v4.0.5

Python version

3.11

Steps to Reproduce

I'm not really sure if this is an issue with the ansible module itself, but might actually be an issue with the pynetbox module. I'm sure the maintainers will have a better idea.

1. Create a redirect scenario on the Netbox server. In our example, we are just trying to redirect HTTP -> HTTPS.
2. Use one of the ansible modules to make a call through the first URL, which should get redirected as part of the initial connection.
3. Instead of following the redirect, or giving a failure to connect error, the code instead continues....
4. The end result is a useless traceback later in the code, when it gets to checking the netbox version number. This happens in different places depending on which specific module is being called.

Expected Behavior

One would expect one of two outcomes here:

1. The call follows HTTP redirect, as most would expect, and succeeds on the updated URL.
2. The call throws a connection failure message, instead of a random traceback later in the code. This could at least give some better feedback on checking connection variables.

Observed Behavior

We were able to work around this issue by updating our ansible variables to the new HTTPS URL, but one really would expect that any request here just follows the redirect. Our server is handing out a proper 301 Moved Permanently code here.

That doesn't appear to be what's happening, as the below traceback doesn't say anything about the connection failing. We only found the fix because we were double checking all our variables and notice we didn't update the URL after recently adding HTTPS.

I'm not sure if this is just not following redirects, or if the netbox module isn't handling connection errors in general. Either way, Ansible has "unreachable" status messages and one would except to get some kind of reasonable feedback that this was a connection failure. Or, better yet, just follow the redirect which would have allowed things to continue here.

"module_stderr": "Traceback (most recent call last):
  File \"<stdin>\", line 107, in <module>
  File \"<stdin>\", line 99, in _ansiballz_main
  File \"<stdin>\", line 47, in invoke_module
  File \"/usr/lib64/python3.9/runpy.py\", line 225, in run_module
    return _run_module_code(code, init_globals, run_name, mod_spec)
  File \"/usr/lib64/python3.9/runpy.py\", line 97, in _run_module_code
    _run_code(code, mod_globals, init_globals,
  File \"/usr/lib64/python3.9/runpy.py\", line 87, in _run_code
    exec(code, run_globals)
  File \"/tmp/ansible_netbox.netbox.netbox_virtual_machine_payload_8fy36nyh/ansible_netbox.netbox.netbox_virtual_machine_payload.zip/ansible_collections/netbox/netbox/plugins/modules/netbox_virtual_machine.py\", line 250, in <module>
  File \"/tmp/ansible_netbox.netbox.netbox_virtual_machine_payload_8fy36nyh/ansible_netbox.netbox.netbox_virtual_machine_payload.zip/ansible_collections/netbox/netbox/plugins/modules/netbox_virtual_machine.py\", line 245, in main
  File \"/tmp/ansible_netbox.netbox.netbox_virtual_machine_payload_8fy36nyh/ansible_netbox.netbox.netbox_virtual_machine_payload.zip/ansible_collections/netbox/netbox/plugins/module_utils/netbox_virtualization.py\", line 25, in __init__
  File \"/tmp/ansible_netbox.netbox.netbox_virtual_machine_payload_8fy36nyh/ansible_netbox.netbox.netbox_virtual_machine_payload.zip/ansible_collections/netbox/netbox/plugins/module_utils/netbox_utils.py\", line 738, in __init__
  File \"/tmp/ansible_netbox.netbox.netbox_virtual_machine_payload_8fy36nyh/ansible_netbox.netbox.netbox_virtual_machine_payload.zip/ansible_collections/netbox/netbox/plugins/module_utils/netbox_utils.py\", line 1197, in _find_ids
  File \"/tmp/ansible_netbox.netbox.netbox_virtual_machine_payload_8fy36nyh/ansible_netbox.netbox.netbox_virtual_machine_payload.zip/ansible_collections/netbox/netbox/plugins/module_utils/netbox_utils.py\", line 748, in _version_check_greater
ValueError: not enough values to unpack (expected 2, got 1)
",

[CompPhy]

Yes, I do know this traceback says Python 3.9... That's because we used Ansible Automation Platform for this first attempt, and execution environments there are based on Python 3.9 at the moment. We did however re-test these same conditions on a development machine, using Python 3.11, and got the exact same results.