Closed martink2 closed 5 years ago
In this example, how would a user replace the contents of net
?
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.
In this example, how would a user replace the contents of net?
I'm wondering what the concrete use-case would be for this?
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.
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.
is there a specific reason that the local config context doesn't use the generic ConfigContextModel
?
@sdktr local config context is one-to-one: It would be much less efficient to store a separate ConfigContextModel
instance for every device.
Environment
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
Context 2
Current Result
Desired Result
Database Changes
None
External Dependencies
None