Skip to content

netbox_device_interface - type or form_factor not accepted #208

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bsmeding opened this issue May 19, 2020 · 11 comments · Fixed by #210
Closed

netbox_device_interface - type or form_factor not accepted #208

bsmeding opened this issue May 19, 2020 · 11 comments · Fixed by #210

Comments

@bsmeding
Copy link

ISSUE TYPE
  • Bug Report
SOFTWARE VERSIONS
Ansible:

ansible 2.9.2

Netbox:

b7a37e8cbe63 (v2.8.4)

Collection:

0.2.1

SUMMARY

The module netbox_device_interface is not accepting the entry: 'type' for media type. Formally known as 'form_factor'. But changed by Netbox version 2.7.
Only the type is not accepted as the module only accept the old 'form_factor'.

"Unsupported parameters for (netbox.netbox.netbox_device_interface) module: type found in data. Supported parameters include: description, device, enabled, form_factor, lag, mac_address, mgmt_only, mode, mtu, name, tagged_vlans, tags, untagged_vlan"}

Only when switching back to form_factor, it works only once. When running second time the error shows:
"msg": "form_factor does not exist on existing object. Check to make sure valid field."}

STEPS TO REPRODUCE
    - name: Check physical interfaces
      netbox.netbox.netbox_device_interface:
        netbox_url: "{{ netbox_url }}"
        netbox_token: "{{ netbox_token }}"
        data:
          device: test-device-01
          name: GigabitEthernet2/13
          type: 1000BASE-T (1GE)
          #form_factor: 1000BASE-T (1GE)
        state: present
EXPECTED RESULTS

OK (Ansible interface setting correct) or Changed:

ACTUAL RESULTS

Error that even the option 'type' is not valid otherwise when using 'form_factor' that the form_factor can only be set on first creation so it is not idempotent.

@FragmentedPacket
Copy link
Contributor

I just released v0.2.1 today and just ran it and appears type does work.

Can you make sure you're actually running v0.2.1?

@bsmeding
Copy link
Author

Yes i do. While opening the issue and get to the point to give current version i looked at git repo an saw laat update 3 hour ago so first updated and tested with version if today. Without success

Does the form_factor also run ok twice?

@FragmentedPacket
Copy link
Contributor

Hm. That is odd. If you navigate to the galaxy.yml within the collections directory, what version does it show? And does anything happen when you run the following command? ansible-galaxy collection install netbox.netbox --force?

And no, that is not fixed and won't be as form_factor was removed in 2.7 and we only support the two latest NetBox versions.

After the command above, do you still get that type is unsupported?

@bsmeding
Copy link
Author

a could not find the galaxy.yml file but the CHANGELOG.md shows lates version

`
root@ansible-nw:/etc/ansible/collections/ansible_collections/netbox/netbox# cat CHANGELOG.md

Changelog

v0.2.1

Enhancements

  • #141 - Added option to change host_vars to singular rather than having single element lists
  • #190 - Added 21" width to netbox_rack
  • #188 - Added cluster, cluster_type, and cluster_group to group_by option in inventory plugin
  • #193 - Added option to flatten config_context and custom_fields

Bug Fixes

after forced reinstallation still same error from Ansible
msg": "Unsupported parameters for (netbox.netbox.netbox_device_interface) module: type found in data. Supported parameters include: description, device, enabled, form_factor, lag, mac_address, mgmt_only, mode, mtu, name, tagged_vlans, tags, untagged_vlan"}

@bsmeding
Copy link
Author

o sorry my fault... had the collection also in the playbook directory that was used and not updated. I found out with running the playbook including -vvvv.
Now the module is updated and used but a new 'error' is raised, the type's are not accepted.

pynetbox.core.query.RequestError: The request failed with code 400 Bad Request: {'type': ['1000BASE-T (1GE) is not a valid choice.']}

ynetbox.core.query.RequestError: The request failed with code 400 Bad Request: {'type': ['Other is not a valid choice.']}

Every type choice I use is declined.

@FragmentedPacket
Copy link
Contributor

@bsmeding Thanks for catching that! I just submitted a PR to fix this.

The PR is #210. Can you please pull and install to test the fix? I'll get it merged after that and waiting on another PR to get tested and then I will cut a new release.

@bsmeding
Copy link
Author

Hi @FragmentedPacket thanks! Don't how how manually get only the pull request changes, but dit the change manually on netbox_utils.py and is working now!

Many thanks!

@bsmeding
Copy link
Author

Don't know it this belong to this issue? If not i will check further or open new issue.

But when updating an existing interface so an LAG group, I need to specify the type now.
It is already in place for this interface, but is not required option, right?

(item=Te2/1/16) => {"ansible_loop_var": "item", "changed": false, "item": "Te2/1/16", "msg": "{\"type\":[\"This field is required.\"]}"}

- name: Set LAG / Etherchannel config
  netbox_device_interface:
    netbox_url: "{{ netbox_url }}"
    netbox_token: "{{ netbox_token }}"
    data:
      device: "{{ ansible_facts.net_hostname }}"
      name: TenGigabitEthernet2/1/16
      type: 10GBASE-T (10GE)
      lag:
        name: Port-channel1

@FragmentedPacket
Copy link
Contributor

That appears to be coming back from the API and not the modules. I'll dig into it, but not entirely sure where the issue lies.

Mind opening a separate issue for that?

@FragmentedPacket
Copy link
Contributor

I did a search and it appears that NetBox does require type to be specified on PUT/PATCH via the API.

@bsmeding
Copy link
Author

ok, in that case it is necessary and not a 'bug' to fix thanks for helping

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants