Device-specific configuration context

[ngrundler]

Environment

• Python version: 3.5.4
• NetBox version: 2.4.4

Proposed Functionality

Configuration contexts are an incredibly useful feature, but as with any standards that we try and apply with a broad brush, there are always exceptions. Our environment is very diverse, and in order to meet the needs of a particular tenant or user group, we are forced to adjust a template or standard to accommodate a request that often impacts only a single device. Extending configuration contexts to a specific device or set of devices would allow us to keep track of these snowflakes. Tagging can solve some of these requests, but often the changes are complex enough that having a configuration context would be more desirable.

Use Case

Some examples I've run into include a user, ssh-key, and permission settings on a single device, a unique login banner, or even enabling a particular protocol required to interoperate with a downstream device. This could also be useful for device-specific hardware settings, e.g. setting the pic-mode for various Juniper devices. Being able to encode this kind of information in an single, external source of authority is very important for us as we try to automate our environment. Right now we're keeping this device-specific information in a separate git repo, but it would be really nice to be able to put all of this in Netbox.

Database Changes

Unknown

External Dependencies

None that I can think of

[lampwins]

This is feasible and has been brought up by a few others already in the mailing list and the NTC slack. I am labeling it as a minor feature because we will need to think carefully through the implications to the data model and avoid scope creep.

My initial impression is that we will allow a single ConfigContext object to be assigned to a Device instance. This particular ConfigContext object will automatically be weighted such that is takes precedence over any other rendered ConfigContexts for the device. Thoughts on this?

[ngrundler]

+1

Just to confirm, other config contexts would still be inherited based on site/tenant etc, but any overlapping values in the device instance context would automatically "win"? That is basically exactly what we're looking for on my end.

[lampwins]

@ngrundler correct, that is the basic idea.

[sdktr]

Why the difference in the 'weighting' for this specific mapping? In general I propose that the priority for conflicting objects from multiple ConfigContext should be:

• weights (higher value wins)
• order according to this (or another fixed) list as tiebreaker (lower in the list wins)
  -- TenantGroup
  -- Tenant
  -- Region
  -- Site
  -- Roles
  -- Platform
  -- Device

[ebusto]

Similarly, it would be helpful to have device type configuration contexts.

This would allow administrators to store BIOS, iLO/DRAC, and other configuration data that makes sense to handle on a per-model basis.