v3.1.0

[FragmentedPacket]

v3.1.0

Release Summary

This release should fix obvious broken changes between collection and Netbox 2.11, but there is most likely more. Please report as they're encountered.
packages is now a required Python package and is already included in Ansible 2.10, but anyone using Ansible 2.9 or below must manually pip install the library.

Major Changes

• packages is now a required Python package and gets installed via Ansible 2.10+.

Minor Changes

• netbox_device_interface - Add label option.
• netbox_device_interface - Add mark_connected option.
• netbox_power_panel - Add location option.
• netbox_rack - Add location option.
• netbox_vlan_group - Add custom_fields option.
• netbox_vlan_group - Add description option.
• netbox_vlan_group - Add scope option.
• netbox_vlan_group - Add scope_type option.

Bugfixes

• Allow virtual_chassis to be found via name #402
• Fix mapping between power_outlet_template and power_port_template.
• inventory - Fix rack-group -> location for NetBox 2.11 changes.
• inventory - Properly handle interface tags.
• netbox_tenant - Fix example to match argspec.

---

This discussion was created from the release v3.1.0.

[FragmentedPacket]

I made a typo that is now propagated, but it is not packages, but instead the packaging Python library.

https://pypi.org/project/packaging/

[bluikko]

In NetBox 2.11 with nb_inventory 3.1.0 now there is a change and discrepancy in how for example tags work:

• In compose, tags is a complex list of dicts with all data like slug, etc.
• In groups, tags behaves normally and is a simple list of strings (tags).

Is this change on purpose? Did I miss it in some documentation?

[FragmentedPacket]

Do you mind providing some more information?

[bluikko]

Sure, I wanted to check first if this change was expected before using more time on this.

Example of how the variable tags looks when used in nb_inventory in compose:

host.domain.example | SUCCESS => {
    "msg": [
        {
            "color": "9e9e9e",
            "display": "tagA",
            "id": 4,
            "name": "tagA",
            "slug": "taga",
            "url": "https://netbox.domain.example/api/extras/tags/4/"
        },
        {
            "color": "9e9e9e",
            "display": "tagB",
            "id": 5,
            "name": "tagB",
            "slug": "tagb",
            "url": "https://netbox.domain.example/api/extras/tags/5/"
        },
        {
            "color": "9e9e9e",
            "display": "tagC",
            "id": 6,
            "name": "tagC",
            "slug": "tagc",
            "url": "https://netbox.domain.example/api/extras/tags/6/"
        }
    ]
}

I believe that in other places the tags is a simple list, for example:

host.domain.example | SUCCESS => {
    "msg": [
        "tagA",
        "tagB",
        "tagC"
    ]
}

[FragmentedPacket]

From preliminary look of it, that may be a regression and hitting an exception that just returns the tags list.

Do you have providing your inventory.yml with any sensitive information removed (token/url)?

And I can take a look.

[bluikko]

---
plugin: netbox.netbox.nb_inventory
api_endpoint: https://api.netbox.domain.example
token: abcd123
validate_certs: true
config_context: false
virtual_chassis_name: true
group_by:
  - sites
  - racks
  - tags
query_filters:
  - role: server
  - status: active
  - tenant_group: enterprise-group
  - platform: el
compose:
  serv_env: ('production' in (tags | json_query('[].slug'))) | ternary('production', ('testing' in (tags | json_query('[].slug'))) | ternary('testing', 'production'))
groups:
  serv_test: "'testing' in tags"

The compose uses the complex list of dicts while groups uses the simple list of strings as listed in my earlier comment example.
A server that has a tag "testing" would thus result in var server_env: "testing" and being in group serv_test.

I have to say that it could be beneficial in some cases to have the more powerful access to the more complex data in compose. It could just be documented (or I missed that documentation).

[bluikko]

As a side note, it might be beneficial to have a way to access the raw API - not only in compose but groups, etc. - as much as possible. The NetBox API could then continue to have a lot of changes and nb_inventory would not need to always try to be quick to adopt those changes. I guess it is a tradeoff between easy use and workload to keep up with the API. Perhaps there could be an option, for those who want it, to trade easy use for more raw API access.