starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Enable 'ConfigContext' to traverse multi-level region heirarchy #1866

New Issue
Closed
opened 2025-12-29 17:19:53 +01:00 by adam · 5 comments
adam commented 2025-12-29 17:19:53 +01:00
Owner
Copy Link

Originally created by @bdlamprecht on GitHub (Jul 24, 2018).

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)":

image

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.

Originally created by @bdlamprecht on GitHub (Jul 24, 2018). ### Issue type [X] Bug report <!-- Unexpected or erroneous behavior --> ### 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](https://github.com/digitalocean/netbox/issues/1366#issuecomment-345772685). To test this feature out, I created a `config_context` named `tacacs` and associated it with the `region` "United States (us)": ![image](https://user-images.githubusercontent.com/7783306/43105322-af80b56a-8e91-11e8-90fc-21fa1de21ea2.png) 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`.
adam added the type: bugstatus: accepted labels 2025-12-29 17:19:53 +01:00
adam closed this issue 2025-12-29 17:19:53 +01:00
adam commented 2025-12-29 17:19:54 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Jul 24, 2018):

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):

image

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?

@bdlamprecht commented on GitHub (Jul 24, 2018): 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): ![image](https://user-images.githubusercontent.com/7783306/43105782-59f0d13c-8e93-11e8-8939-d246b769b86e.png) 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?
adam commented 2025-12-29 17:19:54 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Jul 25, 2018):

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.

@lampwins commented on GitHub (Jul 25, 2018): I started playing with this and came up with this simple solution by coercing an MPTT queryset within the Config Context Manager ```python 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.
adam commented 2025-12-29 17:19:54 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Jul 25, 2018):

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.

@bdlamprecht commented on GitHub (Jul 25, 2018): 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.
adam commented 2025-12-29 17:19:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 27, 2018):

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.

@jeremystretch commented on GitHub (Jul 27, 2018): 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.
adam commented 2025-12-29 17:19:54 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Jul 27, 2018):

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.

@bdlamprecht commented on GitHub (Jul 27, 2018): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#1866
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?