Custom Fields Per Device Type

[techymike]

Hi,

I'm not sure if this is already available or If I've simply missed something, but would it be possible to apply a custom field per device type ?

I can only seem to create custom fields on each actual device, It would be nice to say have a user manual field per every type of server/switch etc at the type level as opposed to every single device.

Apologies if this is already possible

[NetBod]

Beat me to it, I was looking for the same thing last night.....

[jeremystretch]

Can you provide some examples of what you would use this for?

[NetBod]

I was going to use it for End of life/End of Service date for the bit of hardware or software I have configured for the device type, would save having to add the same info many times under the device as a custom field

[techymike]

Hi Jeremy,

Certainly, BTW I love netbox, it's a fantastic tool great job !

In our DC's we have many of the same type of kit, servers, cisco network kit etc. For asset managment and documentation purposes I have a requirement to keep specification/data sheets etc for each piece of kit.
I'm basically adding custom fields containing hyperlinks to the data sheets which point to somewhere on a document server.

At the moment I have to manually enter each field per device, even though potentially scores of devices use the same "data".

It would be nice to say define a custom field for a device type (eg HP Proliant DL380e Gen7 Manual ) and have it applied at the device type level so I don't have to manually add the same field for every server I have.

I'm sure there are probably many other cases where a custom field on the device type level would be of benefit for others. (EOL/EOS date field as NetBod above mentioned is also something that it would be useful for )

Cheers !

[Tigger2014]

This would also be useful for adding device specific notes which apply globally.

[Kevgudge]

We would like to use custom filed for same purpose, warranty contract expiry

[mryauch]

Some of these comments made me drool at the possibilities. I could add links to internal Wiki articles pertaining to specific device models.

[jeremystretch]

I think there's potential for confusing two ideas here:

1. Add support for custom fields to device types. This could be used to track EOS/EOL info, for example. This would be trivial to implement.
2. Display custom fields on individual devices based on their type. So for example, you could say "all Juniper QFX10K switches will have an is_broken custom field." This would be much more difficult to implement.

If all we're talking about is the first one, I'm happy to mark this as an enhancement and work on adding it. Otherwise, lots more discussion is likely needed.

[NetBod]

number 1 from my point of view.
Thanks

[xxiii23]

[...]
2. Display custom fields on individual devices based on their type. [...]

If all we're talking about is the first one, I'm happy to mark this as an enhancement and work on adding it. Otherwise, lots more discussion is likely needed.

In our case, we have wireless devices that we need to record information such as the tilt, azimuth, and beamwidth, the transmit power, the frequency and bandwidth, what modulation modes this device supports, whether or not to show it on maps (in other systems that interface to netbox), what kind/gain of antenna or antennas are attached to this device, FCC callsign, and so on.

We've added a bunch of custom fields to "Device" to support this information, but its irrelevant for almost every other device we track in netbox. (for instance, I don't care what direction my routers are facing, or what the EIRP of my PDUs is, my switches don't have an FCC callsign, etc). meanwhile, we have another class of device that needs a different set of custom fields that external systems need to be able to query/reference.

Maybe we could encode this information in the comments field, but that seems awkward, and i'm not sure how easy it would be for our other systems to utilize the information via that path. Currently our programming team has chosen to just add a bunch of custom fields to "device" and we just ignore them when they are not applicable. At the very least, it would be nice if custom fields could at least specify which device_types they should be visible for (hidden from the rest).

[DanSheps]

You might want to look at config contexts.

[xxiii23]

This seems a bit awkward as we're expecting humans to fill out a form to define a new device, and the form in question just shows a big empty white box for local config context (and a note that its in JSON format), and doesn't even show any applicable outer config contexts for reference.

The custom fields on the other hand show up as fields, with a definite value type and name, and its obvious whats expected.

Perhaps if there was some sort of "front-end" over config contexts that would display them as additional fields and automatically create (or modify) a local context if the user changes the values for any particular device. (basically making them appear as custom fields on whatever the context applies to, while actually storing them as contexts at whatever level is appropriate behind the scenes). This would also do away with the "how come some things are fields, and other things are this programming code thingie" that some of our users might ask/wonder about.

So, we're either left with explaining JSON, and sticky notes with examples on them (and all the potential for errors), or explaining that they just need to ignore the non-applicable fields when working on a device for which they do not apply.

(I see though that config contexts are the answer to my musing about encoding information in the comments field, though my related concerns still seem applicable).

In short, config contexts are not user-friendly from a data-entry point of view.

[jeremystretch]

In our case, we have wireless devices that we need to record information such as the tilt, azimuth, and beamwidth, the transmit power, the frequency and bandwidth, what modulation modes this device supports, whether or not to show it on maps (in other systems that interface to netbox), what kind/gain of antenna or antennas are attached to this device, FCC callsign, and so on.

NetBox is an IPAM/DCIM application, and its scheme is necessarily restricted to holding data directly pertinent to those functions. Custom fields are provided to allow users to define reasonable additional fields, but these are intended for convenience only and should be use sparingly. Alternatively, config contexts are provided for storing large amounts of hierarchically distributed contextual data. If neither of these features suits your need, NetBox is probably not the product you're looking for.

[xxiii23]

Custom fields do suit the need, but it would be nice if they could be applied by device type, instead of all devices, this seems like an obvious extension mechanism to handle those cases that aren't built-in, since the facility for device types already exists.

For that matter, config contexts also fit, (and perhaps better since they can already be limited to what they apply to) other than being difficult and error prone for users.

If we use config contexts we will have to write our own user interface on top of it (treating netbox as an IPAM/DCIM database). I suspect as the path of least resistance though, we'll just live with the custom fields being visible for all devices.

I notice you have PDU devices (which we are using), which allow you to add power outlets. and yet when I add a router device, I can't add power outlets. So it seems you already recognize that not every datacenter device is the same. I'm simply asking that the custom field facility also recognize this; or alternatively:

If a local context exists, or an applicable non-local context exists:

Additional fields a presented, modeled on this context (appearing the way custom fields currently do, but really being the custom context underneath):

If a user alters one or more fields, the underlying local context is either altered, or generated as necessary.

In short, for individual devices, the JSON (or whatever the JSON really turns into) is handled behind the scenes, and users see a friendly, consistent interface when adding/editing a device. (there could be a mechanism provided for advanced/allowed users to still edit the JSON directly).

Someone (in our case, our staff maintaining netbox) will still have to hand-craft the custom context in the device-type (or wherever) that gets used to generate the end result for individual instances. (just like people currently have to create sites/device types/whatever) before handing it over for day to day operations.

If it worked this way, custom fields could probably be done away with entirely, as device contexts would be able to do anything they could do (with the caveat that I am not yet familiar with the Netbox API, so I don't know what the differences there might be).

I offer this as a suggestion for what I think would benefit and make Netbox a more useful and friendly product.

And finally, I'd like to emphasize that we are using this for IPAM/DCIM purposes. For example, we connect our datacenters together with Microwave links, and also with fiber links. We consider recording information relevant to those devices very pertinent to our data center infrastructure and our ability to manage it, but our fiber devices do not need to know where they are aimed or what kind of antenna they have, or what their legal operation parameters are; and our microwave devices don't need to know if they are single-mode or multi-mode, or BIDI, or which fiber strands of a 12 pair bundle are the applicable ones.