An unusual addressing problem for an unusual setup.

[Gordon Pearce]

Hi folks,

I'd like to tag an address onto a piece of kit - several hundred such
pieces of kit, really - in such a way as I can pull out that
information later to create a config file for it.

I thought about adding a custom field, but that adds a custom field to
all devices, and I don't see a way to add it to a single DeviceType.
I did also consider Context Data but the manual suggests that you
shouldn't use it that way in preference to custom fields.

The setup is quite strange and will only be familiar to people who
have worked with the emergency services in the UK, Eire, NZ and parts
of Australia. Think in terms of a custom rackmount PC with an address
like 099:1234 where the first part represents "brigade" and the second
is from 0-4095 and represents "node number". Any given bit of kit
will have exactly one node number but any Location may have more than
one bit of kit with a node number. The devices know their own brigade
and node number, and that of anything they need to route to or receive
from, but other than that the routing is pretty static.

The gist of it is though that this is a per-device address that can be
reached through several interfaces with a variety of IP addresses or
indeed telephone numbers. I thought about maybe just adding a dummy
interface to it, but that seems a bit messy.

There are a bunch of other locally-applicable settings per encoder,
like pager codes and printer templates.

Am I totally misunderstanding the bit about using custom fields
instead of local context data? Would context data be a better fit?

Would it be hard to get the Django template for a particular device to
show "interpreted" JSON context data?

Gordonjcp

[Brian Candler]

Not knowing the problem space deeply, it sounds to me like this is some sort of label on a device, so a custom field on device is where I'd start.  You can't prevent the field from being displayed on other device types, but you should be able to use a custom validation rule to prevent it being set to a non-empty value except on certain device types; I believe you could also use custom validation to enforce its uniqueness if required. (There is a theoretical problem with race conditions, e.g. if two users try to set the same ID at the same instant in time it may be permitted, but the window when this can happen is small, and use a report to check for violations)

A dummy interface sounds more difficult to use. You'd still need a custom field on Interface for the node id (unless you made it part of the interface name?), and it would be harder to enforce that each device has no more than one of these dummy interfaces.

Config contexts are JSON blobs, and must be edited directly as JSON, so aren't very user-friendly (but this may not matter if they are set once and left alone).  You can set config context data directly on a device, but you can also set it on other things (e.g. sites, device types, roles) which are related to devices.  See note here.  When you call get_config_context() on a device you get the merged JSON data from all the contexts related to this device, with final override from the local_context_data.  It's most useful for values which are normally shared by all devices with the same (site / device type / role etc), but maybe need to be overridden for specific instances.  For example, if the "brigade" value was normally the same for all devices in the same site, then config contexts would be one way to model that, to avoid setting it an all devices individually.

If you feel that neither custom fields nor config contexts meet your needs well, then you can consider writing a plugin.  It's more effort, but gives you more flexibility.

> Would it be hard to get the Django template for a particular device to show "interpreted" JSON context data?

As far as I know, you should be able to call object.get_config_context() within a Django template.  Which Django templates are you thinking of - export templates?

[Gordon Pearce]

> A dummy interface sounds more difficult to use. You'd still need a custom field on Interface for the node id (unless you made it part of the interface name?), and it would be harder to enforce that each device has no more than one of these dummy interfaces.

It's not the end of the world if that can't be enforced, because these
are going to be created from a script and only Editable By Grownups.

> You can set config context data directly on a device, but you can also set it on other things (e.g. sites, device types, roles) which are related to devices.

That hadn't occurred to me but it solves part of one problem, in that
there are requirements like "each station has to report back to these
two management terminals that might change, but each region's stations
have to talk to these control stations in their area".

> If you feel that neither custom fields nor config contexts meet your needs well, then you can consider writing a plugin. It's more effort, but gives you more flexibility.

This is kind of where I've got to with it, although for now what I'll
probably do is just write some export scripts to get a prototype
working and worry about making it pretty later.

Being blunt about it, the only time that people who aren't intimately
familiar with the workings of GD92 and the weirdass config issues it
throws up are going to be looking at this, is when we are blinding
managers with science. So if it looks a bit hard to use, it'll
possibly discourage them from taking too much of an interest.

> s far as I know, you should be able to call object.get_config_context() within a Django template. Which Django templates are you thinking of - export templates?

If you look at a Device now, it has things like a box for Services
that it supports, which aren't necessarily useful for everything (does
a PoE midspan have services?). What I'd like to be able to do is for
a specific DeviceType, render a custom template for a Device that
shows stuff that is locally relevant to it. So in the case of my
encoders, in the Services box it might show its node address, pager
address, linked nodes and so on. I realise I could do this with a
deep dive into the Netbox code which would "invalidate the warranty",
and actually implementing something like this in Netbox itself would
be a modification of Zawinski's Law in that every web app eventually
becomes a CMS ;-)

I could just write a script that'll populate the Device comments field
with a description of what's going on with that encoder.

I think for the future the plugin route is the way forward. Given how
easy it is to export out, mangle, and import back in data, I can
probably make something up to do the bulk of the work and worry about
fine detail later.

Gordon

> --
> You received this message because you are subscribed to the Google Groups "NetBox" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discus...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/4d8bf688-e55a-4e45-b88f-3a5aebfba64cn%40googlegroups.com.

[Brian Candler]

On Tuesday, 21 December 2021 at 12:29:51 UTC gord...@gmail.com wrote:

> You can set config context data directly on a device, but you can also set it on other things (e.g. sites, device types, roles) which are related to devices.

That hadn't occurred to me but it solves part of one problem, in that
there are requirements like "each station has to report back to these
two management terminals that might change, but each region's stations
have to talk to these control stations in their area".

Yep, that's a very good example of what config contexts are for.  Even simple stuff like "what DNS caches should I use?" works well for this too.

 

If you look at a Device now, it has things like a box for Services
that it supports, which aren't necessarily useful for everything (does
a PoE midspan have services?). What I'd like to be able to do is for
a specific DeviceType, render a custom template for a Device that
shows stuff that is locally relevant to it.

The layout is indeed fixed, the same for all devices - and therefore there are fields displayed which may not be relevant in a given context.

If you wanted multiple layouts, I don't think it's as simple as linking layouts to Device Types.  Some people might want different layouts for different Device Roles, for example, or for different types of user.  So I think you'd need some sort of calculated property, which based on the attributes of a given device and the authenticated user, decides which layout to use.  Salesforce does all that sort of stuff.

Of course, you could also make a minimal web interface to the REST API and make that available to users who don't need to see the full Netbox interface.

Regards,

Brian.