Expose non-device data via GraphQL

[jlanclos]

Allow query beyond device level, expose as "external_data"

Example, need data for all VRFs, not just ones attached via interface->address->vrf.

GraphQL:

query ($device_id: ID!) {
  vrfs { 
      id 
      name 
      prefixes { 
        id 
        prefix 
     } 
  }
  device(id: $device_id) {
    virtual_chassis {
      id
      name
      master {
        id
        name
      }
      members {
        id
        name
        primary_ip4 {
          address
        } 
      }
    }
.....

Any non device data is under external_data external_data.vrf.prefixes

[itdependsnetworks]

I am not sure I follow the issue with putting this within the device?

[ghost]

The device level doesn't expose enough information to configure Layer 3 and EVPN underlay. A switch/router may not have any interfaces in a VRF, but still needs that VRF information to configure proper routing/route-leaking via MP-BGP.

[itdependsnetworks]

Sorry, I am still confused, your query still works, is the point here an optimization in key names? If so see the https://graphql.org/learn/queries/#aliases feature of graphql.

[ghost]

It is not possible to query all VRFs (or anything not linked to the device) from within a device model. Due to this only 'device' will ever be returned, regardless of any queries ran outside the device model.

Maybe I'm missing something with GraphQL, but I'm not seeing a way to query outside of a linked structure.

[itdependsnetworks]

ok, I better understand now, I had changed this and forgotten that step was enforced https://github.com/nautobot/nautobot-plugin-golden-config/blob/e911cf5b229900f69fd8792ed6b1a92db9ebc55a/nautobot_golden_config/utilities/graphql.py#L39

[itdependsnetworks]

Going to try and collect feedback internally how to best approach this. If we decide to go this route, would require documentation and tests. That being said, don't want to make you go through all of that and then go with another solution.

[itdependsnetworks]

The solution is painfully obvious to me. We should just link another linked saved query to the Settings model, and allow people to use that and stuff under a specfic key like _data.

[grahamjohnston]

@itdependsnetworks, will that allow someone to filter results, or only allow me global access to data such as all vrfs as with the original example? I've got a use case where I'd like to get device data, but from a different vantage point and need to be able to filter still. See example below. Maybe my real problem is inconsistent typing for device_id between different objects.

query ($device_id: ID!, $device_id_str: [String]) {
  device(id: $device_id) {
    hostname: name
    primary_ip4 {
      address
    }
    interfaces {
      name
      description
      enabled
      tagged_vlans {
        id
      }
      untagged_vlan {
        id
      }
    }
    config_context
  },
  ipv4_addresses: ip_addresses(device_id: $device_id_str, family: 4){
    address
  },
  ipv6_addresses: ip_addresses(device_id: $device_id_str, family: 6){
    address
  }
}```