Leveraging keyed_groups, config context and multi-level arrays with nb_inventory

[td-raystevens]

We currently use netbox and would like to manage this through Ansible automation platform, leveraging the nb_inventory plugin.

There are concerns about using the currently available options under group_by due to the likely complexity of the tagging structure and the responsible team would like instead, to use the config context option to store the relevant host information.

I have tried in a variety of ways to leverage this but without much success and at this point, i'm not sure it's possible.

Where i'm at so far is using keyed_groups:

   - parent_group: autogen
     prefix: new_var
     key: layer_one.layer_two[0].name

but this has the obvious flaw that it can only reference the first object in the array for both the groups and which hosts end up in said groups.
i.e.

HOST 1:
"layer_one": {
    "layer_two": [
      {
        "name": "value_A",
      },
      {
        "name": "value_B",
      }
    ]
  }

HOST 2:
"layer_one": {
    "layer_two": [
      {
        "name": "value_B",
      },
      {
        "name": "value_A",
      },
      {
        "name": "value_C",
      }
    ]
  }

Would create two groups, new_var_value_A and new_var_value_B and each would only have one host in each even though both have those values in their array because it's the first object in the list

The goal would be to iterate through layer_two and create as many groups as exist for the values of name (in this case, three groups) then assign the host to each group which is applicable, new_var_value_A (two hosts) new_var_value_B (two hosts) and new_var_value_C (one host)

I've tried a few different options, none of which produce any results at all

key: layer_one.layer_two[0,1,2,3].name
key: layer_one.layer_two[0-100].name
key: layer_one.layer_two[*].name
key: layer_one.layer_two[%].name
key: layer_one.*.name
key: "{{ layer_one.layer_two | map(attribute='name') | list }}"

Does anyone have an alternative approach i've missed?
We need something that does the equivalent of

{%  for layer_two in layer_one.layer_two %}
  {{ layer_two.name }}
{% endfor %}

[sc68cal]

I think it is probably best to investigate the nb_lookup plugin. It is more flexible and you have more control over the queries.

[td-raystevens]

@sc68cal can you provide an example that you've tested as working for the inventory plugin that achieves this? It is unclear to me what is missing that would be relevant

[sc68cal]

It is the nb_lookup plugin, not the inventory plugin. As for providing an example, no I do not have an example on hand besides lookups that I have done on the devices API endpoint.

    - name: Create point to point /31's for VM
      tags:
        - p2p
      netbox_prefix:
        netbox_url: "{{ netbox_url }}"
        netbox_token: "{{ netbox_token }}"
        data:
          site: "{{ netbox_lab_site }}"
          prefix: "{{ point_to_point_block | ansible.netcommon.ipsubnet(31, ansible_loop.index0) }}"
          description: "{{ item[0].value.name }} - {{ item[1] }}"
      loop_control:
        extended: yes
      loop: "{{ lookup('netbox.netbox.nb_lookup', 'devices',
                api_filter='site=lab' + ' role=leaf',
                api_endpoint=netbox_url,
                token=netbox_token) | product(['port-channel 17', 'port-channel 18', 'port-channel 19', 'port-channel 20']) }}"

[td-raystevens]

Right, but this was a query about how to achieve the desired endgoal with the inventory plugin. If it was a task, I could just set the values I need and loop the query. I was under the impression you were suggesting to use the lookup plugin within the inventory definition. If that's not the case, it's not a solution to my problem.

The goal is to create a dynamic inventory that is consumed by Ansible Automation Platform and leveraging lookups within playbooks is not an option

[sc68cal]

I don't quite understand why lookups are not allowed within the playbooks that you are writing, that are run against AAP. You can still use the nb_inventory plugin to generate your dynamic inventory. You would then create some tasks where you do a nb_lookup and then probably the api_filter would include something like device={{inventory_hostname}} or an equivalent.

[td-raystevens]

It's not that lookups aren't allowed, it's that the users leveraging this inventory have nothing to do with netbox, no permissions to access it. We can not require them to have the details we store in netbox/write additional lookups in order to be able to target specific groups of hosts

For our use case, we need the groups to exist in the inventory.