Allow Config Contexts to be deep merged #2048

New Issue

adam · 2025-12-29T17:21:45+01:00

adam commented

2025-12-29 17:21:45 +01:00

Originally created by @martink2 on GitHub (Oct 6, 2018).

Environment

Python version: 3.5.2
NetBox version: 2.4.5

Proposed Functionality

Netbox allows Context data to be provided in a hierarchical fashion via JSON
and also allows merging multiple Contexts. The current merge overrides the
entire subtree if a later Context includes the same keys. For large organised
Context data it would be more desirable to merge not only based on "top level"
keys but also merge further down in the key hierarchy by performing a deep merge
as many YAML/JSON config based automation tools like Chef or Ansible do.

Use Case

Use deep merged JSON config directly in Ansible or Chef.
Example of desired Behaviour:
Context1

{
    "cc": {
        "net": {
            "vrf": {
                "cc-cloud01": {
                    "global-rt-export": [
                        101
                    ]
            }
        }
    }
}

Context 2

{
    "cc": {
        "net": {
            "vpn_asn": 65126
        }
    }
}

Current Result

{
    "cc": {
        "net": {
            "vpn_asn": 65126
        }
    }
}

Desired Result

{
    "cc": {
        "net": {
            "vpn_asn": 65126,
            "vrf": {
                "cc-cloud01": {
                    "global-rt-export": [
                        101
                    ]
            }
        }
    }
}

Database Changes

None

External Dependencies

None

Originally created by @martink2 on GitHub (Oct 6, 2018).  ### Environment * Python version: 3.5.2 * NetBox version: 2.4.5  ### Proposed Functionality Netbox allows Context data to be provided in a hierarchical fashion via JSON and also allows merging multiple Contexts. The current merge overrides the entire subtree if a later Context includes the same keys. For large organised Context data it would be more desirable to merge not only based on "top level" keys but also merge further down in the key hierarchy by performing a deep merge as many YAML/JSON config based automation tools like Chef or Ansible do.  ### Use Case Use deep merged JSON config directly in Ansible or Chef. Example of desired Behaviour: Context1 ```json { "cc": { "net": { "vrf": { "cc-cloud01": { "global-rt-export": [ 101 ] } } } } ``` Context 2 ```json { "cc": { "net": { "vpn_asn": 65126 } } } ``` Current Result ```json { "cc": { "net": { "vpn_asn": 65126 } } } ``` Desired Result ```json { "cc": { "net": { "vpn_asn": 65126, "vrf": { "cc-cloud01": { "global-rt-export": [ 101 ] } } } } ```  ### Database Changes None  ### External Dependencies None

adam added the status: accepted type: feature labels 2025-12-29 17:21:45 +01:00

adam closed this issue

2025-12-29 17:21:45 +01:00

adam commented

2025-12-29 17:21:45 +01:00

@jeremystretch commented on GitHub (Oct 9, 2018):

In this example, how would a user replace the contents of net?

@jeremystretch commented on GitHub (Oct 9, 2018): In this example, how would a user _replace_ the contents of `net`?

adam commented

2025-12-29 17:21:46 +01:00

@martink2 commented on GitHub (Oct 9, 2018):

In chef (im am using this example as i am most familiar with that one) the idea is one does
not. Dicts are only used to structure data so values are the leafs of the config tree and you can
replace any of those by just setting them to something different or null.

You could force this in the example by setting:

{
    "cc": {
        "net": null
        }
    }
}

and

{
    "cc": {
        "net": {
            "abc": 126
        }
    }
}

which would leave you with an "override"
another option would be to introduce a setting
on the context itself if it should be handled
as "merge" or "override". The library used in
the PR would make that easy to implement.

@martink2 commented on GitHub (Oct 9, 2018): In chef (im am using this example as i am most familiar with that one) the idea is one does not. Dicts are only used to structure data so values are the leafs of the config tree and you can replace any of those by just setting them to something different or null. You could force this in the example by setting: ```json { "cc": { "net": null } } } ``` and ``` { "cc": { "net": { "abc": 126 } } } ``` which would leave you with an "override" another option would be to introduce a setting on the context itself if it should be handled as "merge" or "override". The library used in the PR would make that easy to implement.

adam commented

2025-12-29 17:21:46 +01:00

@cimnine commented on GitHub (Oct 9, 2018):

In this example, how would a user replace the contents of net?

I'm wondering what the concrete use-case would be for this?

@cimnine commented on GitHub (Oct 9, 2018): > In this example, how would a user replace the contents of net? I'm wondering what the concrete use-case would be for this?

adam commented

2025-12-29 17:21:46 +01:00

@jeremystretch commented on GitHub (Oct 9, 2018):

I'm wondering what the concrete use-case would be for this?

Removing a widely applicable piece of data only for a small subset of devices, such as in a lab or other niche area or role. It's a function that NetBox supports today, so every effort should be made to preserve it.

another option would be to introduce a setting on the context itself if it should be handled as "merge" or "override".

This would probably be the preferred approach. We can introduce a boolean field on the ConfigContext model to specify the behavior, defaulting to merge.

@jeremystretch commented on GitHub (Oct 9, 2018): > I'm wondering what the concrete use-case would be for this? Removing a widely applicable piece of data only for a small subset of devices, such as in a lab or other niche area or role. It's a function that NetBox supports today, so every effort should be made to preserve it. > another option would be to introduce a setting on the context itself if it should be handled as "merge" or "override". This would probably be the preferred approach. We can introduce a boolean field on the ConfigContext model to specify the behavior, defaulting to merge.

adam commented

2025-12-29 17:21:46 +01:00

@lampwins commented on GitHub (Oct 9, 2018):

Just a note for when it comes time to implement this, the same boolean field will need to be added to the Device and VirtualMachine models by way of the ConfigContextModel. This is unless we want the local_context_data to only every use one method (merge or replace), which I don't think makes much sense.

@lampwins commented on GitHub (Oct 9, 2018): Just a note for when it comes time to implement this, the same boolean field will need to be added to the Device and VirtualMachine models by way of the ConfigContextModel. This is unless we want the `local_context_data` to only every use one method (merge or replace), which I don't _think_ makes much sense.

adam commented

2025-12-29 17:21:46 +01:00

@sdktr commented on GitHub (Oct 15, 2018):

is there a specific reason that the local config context doesn't use the generic ConfigContextModel?

@sdktr commented on GitHub (Oct 15, 2018): is there a specific reason that the local config context doesn't use the generic ```ConfigContextModel```?

adam commented

2025-12-29 17:21:46 +01:00

@jeremystretch commented on GitHub (Nov 5, 2018):

@sdktr local config context is one-to-one: It would be much less efficient to store a separate ConfigContextModel instance for every device.

@jeremystretch commented on GitHub (Nov 5, 2018): @sdktr local config context is one-to-one: It would be much less efficient to store a separate `ConfigContextModel` instance for every device.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#2048