> 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.
> 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