Referencing host variables under the new List of Dicts schema

[rich9474]

Hi. I am trying to reference some host variables in a Jinja2 template. but am unsure of the correct/optimal way of doing it. In a multi DC config, I have the node types l2leaf, l3leaf and spine for each DC. For example a l3leaf pair in one:

l3leaf:
  node_groups:
    - group: DC1_WAN
      platform: 7280R3
      mlag: false
      nodes:
        - name: loynwan1a
          id: 1
          bgp_as: '65001.1'
          mgmt_ip: 10.255.0.105/24
          mac_address: 11:11:11:11:11:11
          rack: "101"
        - name: loynwan1b
          id: 2
          bgp_as: '65001.2'
          mgmt_ip: 10.255.0.106/24
          mac_address: 22.22.22.22.22.22
          rack: "201"

Using the Ansible debugger I can see I can't just reference the hostvars[host].mgmt_ip to get the ip address, but rather every host in that DC of the same node type has a list with all of the other hosts of the same DC/Type in vars()["task_vars"]["hostvars"][host]["l3leaf"]. The host vars will be in a list under either ["node_groups"][group_list_element]["nodes"] or ["nodes"] given nodes are not always in a group, to get to the list of nodes vars I would need to search:

each group_list_element in vars()["task_vars"]["hostvars"][host]["l3leaf"]["node_groups"][group_list_element]["nodes"] and
vars()["task_vars"]["hostvars"][host]["l3leaf"]["nodes"]

I need to search all lists and return just that hosts entry wherever it is. but I don't know what node_group the hosts parent is, I would need to iterate all groups and work out if the host was a member of the ones in this list. I could then get the groups list of nodes. For each host, I would need to iterate the node_types, each node_groups and nodes, to work out where the information is.

To jump through those hoops every time seems like a lot of work and inefficient, so I am guessing/hoping that there is a more elegant way to do this that I am unaware of. If someone can please enlighten me, I would be very grateful.

[ClausHolbechArista]

Hi Rich, if you are running this as part of an AVD playbook, you can leverage some of our internal
switch.* facts, but please note that these are subject to change without notice! We are working on defining a set of stable facts you can use for this in the future.

{{ hostvars.lyonwan1a.switch.mgmt_ip }}

should have what you need here.

You can find other vars here, but again your mileage may vary. Let us know which ones you need, so we can try to cover it. Also it would be good to know what you need them for, so we can provide a native feature instead.

[rich9474]

Hi Claus. Thanks for the swift response. I knew there would be an easier way. In the current case I am extending the arista.avd.dhcp_provisioner and arista.cvp.dhcp_configuration to allow me to get the info from the AVD inventory, rather than having to define things like the mgmt_ip in multiple places. The current arista.avd.dhcp_provisioner can use the inventory, but only for a single subnet management network. I need multiple DCs and management subnets, in addition to being able to list other devices that need a pinned DHCP address. It also needs updating to support the new List of Dicts schema.

That page you linked is a wealth of information I hadn't yet discovered, so thanks for that.

[rich9474]

It looks like I can run:

    - name: Set eos_designs facts
      arista.avd.eos_designs_facts:
        avd_switch_facts: true
        #cprofile_file: "eos_designs_facts.prof"
        template_output: true
        # conversion_mode: "{{ avd_data_conversion_mode }}"
        # validation_mode: "{{ avd_data_validation_mode }}"
      check_mode: false
      run_once: true

    - name: DEBUG - switch facts
      debug: 
        msg: "Management  IP = {{ avd_switch_facts[inventory_hostname].switch.mgmt_ip }}"

at the beginning of my DHCP provisioning playbook, and then just reference the list of devices in the var avd_switch_facts, so that makes everything a lot easier.

[ClausHolbechArista]

While that will work, again please notice my warning of future changes. I doubt we will remove mgmt_ip any time soon, at least without some replacement, but these switch.* facts should be used carefully.
I will note your use of mgmt_ip, so I make sure to include that in the stable facts. If you use other things, please let me know.