How to generate hierarchical configuration without configuration contexts on site and location.

[amuckart]

We're using Netbox to generate LLDP configuration for our devices, including granular location information which is important for our use case and we're running into an issue getting site and location information in a useful way.

The address field in a site is unstructured text and seems over complicated to get at from a device and because it's unstructured text decomposing it into fields for the LLDP config is difficult to do consistently.

Configuration contexts don't seem to exist at site group, site or location level, and I'm not sure why. We certainly have bits of config information that are set at each of those levels.

We could do this with custom fields, but that would add a lot of custom fields to the site view replicating information that's already there. Making them hidden in the UI would clean up the view but make editing and finding errors harder.

For us, the ideal solution would be to be able to apply configuration contexts to site groups, sites, and locations (not just for LLDP, but also for things like log servers, print servers, routing info, etc. etc.). That would make generating this kind of hierarchical data trivially easy and it would map very simply on to the equipment we're generating configurations for.

Absent that, I'd be interested in how other people are solving this problem.

Thanks.

[candlerb]

The address field in a site is unstructured text

I would also like addresses to have a degree of structure (at least postal code), but the decision was that no format suits everyone, so if you need a structured address, add it as custom fields. See #13973, #12399, #9617, #1009.

Configuration contexts don't seem to exist at site group, site or location level, and I'm not sure why

Config contexts can be associated to all of those things:

However, they are only assembled together for a Device or a Virtual Machine. This is because their sole purpose is for creating configs for devices or virtual machines.

For example: if you're creating a config for device X, and the device in site S, then the config context assigned to site S will be pulled in. This will merged with the other config contexts which the device relates to (e.g. location, device type, role etc), in order of weight, and finally will be updated by the device's local context data, which takes precedence over all of those.

Config contexts are not intended for auxiliary data on other types of object, such as (in your case) more specific address information. That's what Custom Fields are for.

I agree that replacing the whole address field with custom fields would be messy, if you can't hide the Netbox physical address and shipping address fields. You could however add a custom validation rule which says that the physical address and shipping address must be left empty - this would ensure there is no data duplication or inconsistencies.

[MoratNZ]

Unfortunately only the immediate parent location gets included in the rolled-up config context. So if you have a hierarchy of locations (e.g., as we do, row > room > floor) between device and site, only the first (row, in this case) gets included.

'Rack' is not included at all, as you can't attach config contexts to racks.

[MoratNZ]

Having had a look in the code, this appears to be due to the way the ConfigContextQuesrySet is being build in https://github.com/netbox-community/netbox/blob/a9a012daf02d5ddfe043b6643cde0c99447202aa/netbox/extras/querysets.py - it's just grabbing the directly attached location at line 26, not recursing through parent locations.

I'm not sure how much of a pain it would be to alter that behaviour

[candlerb]

Ancestors are matched for regions and site groups already, so it might not be too hard to do the same for locations:

netbox/netbox/extras/querysets.py

Lines 36 to 42 in a9a012d

	# Match against the directly assigned region as well as any parent regions.
	region = getattr(obj.site, 'region', None)
	regions = region.get_ancestors(include_self=True) if region else []
	# Match against the directly assigned site group as well as any parent site groups.
	sitegroup = getattr(obj.site, 'group', None)
	sitegroups = sitegroup.get_ancestors(include_self=True) if sitegroup else []

Config contexts at rack level seem a reasonable suggestion too (after all, "location" was previously "rack_group")

You could raise those as two feature requests.

[amuckart]

Thank you Brian. I'll raise a couple of feature requests for that.

[amuckart]

Hi Brian, thanks for replying.

However, they are only assembled together for a Device or a Virtual Machine. This is because their sole purpose is for creating configs for devices or virtual machines.

For example: if you're creating a config for device X, and the device in site S, then the config context assigned to site S will be pulled in. This will merged with the other config contexts which the device relates to (e.g. location, device type, role etc), in order of weight, and finally will be updated by the device's local context data, which takes precedence over all of those.

That's exactly what we're doing - building configuration for LLDP that is based on hierarchical context data for a given device.

Some of the data we need is kind-of stored in other places, but not in a usable or easily accessible way, and most of it is not.

Config contexts are not intended for auxiliary data on other types of object, such as (in your case) more specific address information. That's what Custom Fields are for.

To me, this isn't "more specific address information" it's "configuration context to build the LLDP config we need on devices". It's also the case that the delivery address on the site object isn't necessarily the same as the physical address we need in LLDP, so this very much is 'configuration context' not "auxilliary site data".

Custom Fields have a lot of limitations for this kind of task, not least of which is that the UI ends up horribly cluttered because the controls over where and how they appear are so limited. They also can't be pulled in from a Git data source like configuration context data is, so the entire workflow of managing and revision controlling them is not really fit for this purpose.

Thanks.