Enable 'ConfigContext' to traverse multi-level region heirarchy

[bdlamprecht]

Issue type

[X] Bug report

Environment

• Python version: 3.6
• NetBox version: v2.4-beta1

Description

First off, let me personally thank you for implementing this feature. I believe this was a huge effort and will only drive more people to start using NetBox.

In my scenario, I have a multi-level region heirarchy as described here.

To test this feature out, I created a config_context named tacacs and associated it with the region "United States (us)":

Then I tried querying a device which resides in the site named bld, which is in a child region named Boulder, CO. When this happened, I received a blank "config_context": {}.

Then, per a recomendation from jeremystretch, I moved the association from the parent region "United States (us)" to the child region "Boulder, CO" and then queried the same device and got back the information I wanted (snipped for brevity):

"comments": "",
  "tags": [],
  "custom_fields": {},
  "config_context": {
    "tacacs": {
      "primary": {
        "ip": "10.89.176.190",
        "port": "49165"
      },
      "secondary": {
        "ip": "10.89.45.254",
        "port": "49165"
      }
    }
  },

This request it to enable traversing several layers of parent-child regions to create the appropriate config_context.

[bdlamprecht]

Also, I didn't think this meritted it's own FR, but the dialog boxes in the WebUI for config_contexts are quite small (appears to be only 4 lines tall):

Would it be possible to make those a little bit larger (at a minimum 8 lines tall for each Model) or even possibly allow the user to change them after the page renders similar to the Data window?

[lampwins]

I started playing with this and came up with this simple solution by coercing an MPTT queryset within the Config Context Manager

class ConfigContextQuerySet(QuerySet):

    def get_for_object(self, obj):
        """
        Return all applicable ConfigContexts for a given object. Only active ConfigContexts will be included.
        """

        # `device_role` for Device; `role` for VirtualMachine
        role = getattr(obj, 'device_role', None) or obj.role

        # we must account for nested regions
        region = getattr(obj.site, 'region', None)
        if region:
            regions = region.get_ancestors(include_self=True)
        else:
            regions = []

        return self.filter(
            Q(regions__in=regions) | Q(regions=None),
            Q(sites=obj.site) | Q(sites=None),
            Q(roles=role) | Q(roles=None),
            Q(tenants=obj.tenant) | Q(tenants=None),
            Q(platforms=obj.platform) | Q(platforms=None),
            is_active=True,
        ).order_by('weight', 'name')

Note however that the region hierarchy does not affect the rendering of the context directly. You would still need to apply the appropriate weights to the contexts at each region to basically rebuild the region hierarchy within the Config Context hierarchy. I think this makes sense because it doesn't do anything fancier than what is implemented today, it just allows including the contexts from all the applicable regions in the tree.

Not sure if we want to prerender the region tree context or otherwise order it specifically in the resulting queryset? That seems complicated and will likely result in additional queries needed to render a region tree context.

[bdlamprecht]

I don't understand what you're doing with this code, but if it makes it possible to do what I described in the bug report, I'm all for it. However, one thing you mentioned made me somewhat concerned:

You would still need to apply the appropriate weights to the contexts at each region to basically rebuild the region hierarchy within the Config Context hierarchy.

From the way I interpret that, I'd prefer not to have to put weights at each level of the region hierarchy if at all possible, that seems tedious. That may not be what you intended to describe, and if not, great.

[jeremystretch]

So suppose you have three regions forming a tree:

Europe
  - Germany
    - Frankfurt

And you have a site assigned to Frankfurt. I think the caveat is that a context applied to Frankfurt or Germany won't automatically take precedence over a context applied to Europe: Weight will be evaluated irrespective of each region's position in the hierarchy.

This should be pretty easy to work around so long as you give some forethought to weighting. For example, you might say countries have a weight between 100 and 199, and cities have a weight between 200 and 299. Something like that.

Also keep in mind that weights only come into play when two or more contexts have conflicting values. So if you define foo at the country level and bar at the city level, it's not a concern anyway.

[bdlamprecht]

Yeah, okay, that idea about coming up with a schema for weights works for me.

Honestly, most of the ConfigContexts that I would use would be set at the geographic region level (EMEA, APAC, etc).

Only in certain circumstances would a country have it's own values (i.e. China tends to have certain government policies that we'd have to work around and perhaps India too). Very rarely would a city/specific site have it's own settings.