jinja based custom field type

[ryanmerolle]

NetBox version

v3.1.4

Feature type

New functionality

Proposed functionality

Similar to export templates usage of jinja and object relationships, it would be nice to have a custom field type that is generated solely based on jinja.

Use case

A basic use case would be to auto generate interface descriptions based on the remote peer (interface & device name) or even the circuit ID & carrier name if connected to a circuit.

Database changes

No response

External dependencies

No response

[jeremystretch]

A basic use case would be to auto generate interface descriptions based on the remote peer (interface & device name) or even the circuit ID & carrier name if connected to a circuit.

I'm not sure I understand the use case for this. Why wouldn't this be done on the client side? Off the bat, I can see several issues:

• The overhead imposed by rendering these fields occurs every time, regardless of whether the value is actually needed by the client.
• Accessing data beyond what's provided in the model being queried greatly complicates database querying, and can easily lead to performance issues.
• Any changes to the field's template can potentially effect a breaking API change, which is not communicated to the client.

[ryanmerolle]

1. I think most people (including myself) do this on the client side currently. It would be nice to have it viewable in the UI and stored in NetBox. To your point its not a must.
2. Fair point on overhead. Other DCIM solutions handle this on the server & the custom links model does something similar. I figured I would ask since I have seen users ask about a similar feature. If something we are not doing, its good to have an issue so people can see why.
3. The API impact is not something I thought of. Most people would be ok with that because they likely interface with the API as opposed to outside resources. But this is a good point.

[sdktr]

It should only render in the api response if explicitely requested by the client. Like a regular custom field the format can indeed change over time, this is inheritely to the self defined field imo.

The big advantage is the fields are defined once, instead of multiple places like multiple export templates, script and within the external clients.

+1 vote from me🙂

[jeremystretch]

It should only render in the api response if explicitely requested by the client.

This is not how a REST API is intended to function, and should be considered an anti-pattern to be avoided. The only place we currently allow toggling a specific field is device/VM config contexts (and I'd prefer to eliminate that).

Like a regular custom field the format can indeed change over time

This is not typical for a custom field. Once you've defined, for example, an integer custom field, it is unlikely that you'll later change it to e.g. a string type. But if you do, at least the new type is conveyed in the custom field's type field. Not so with a rendered template, which is completely arbitrary.

[jeremystretch]

Also consider this scenario: The owner of an API client (client A) introduces a template-based custom field for its client use. Then, the owner of a separate client (client B) discovers this field and begins to use it as well. After some time, the owner of client A determines that a change is necessary, and modifies the template to change the format of its output. This breaks client B.

The owner of client B then complains (or worse, reverses the change unilaterally, breaking client A). Now we have a disagreement with one side arguing that the other needs to update their client to accept the new format, and the other rebutting that the API should not have been changed in the first place. It is easy to imagine such a scenario arising very frequently with such an implementation. And the entire problem could have been avoided if both clients had merely invested some small effort to consume the data that is already available to them in a well-defined format.

[ryanmerolle]

I think your scenarios are fair, but not super common. Would not the same scenario be possible for any custom field that a client references and is changed on the fly by an admin. IE the name of the field, the data type, or just the value someone might be keying on in their scrip/app.

I have invested time on the logic on the client side. I may even invest in logic for NetBox scripts to auto update the interface descriptions if this feature was not to be taken up. It would not be that hard to do given I have the logic already defined on the client side. Frankly, this would allow for native interface description data stored in a core NetBox interface attribute. I recognize that others may not have my exact interface description use case, but I'm sure there are some other use cases where an existing NetBox attribute won't do. I also think people in their effort to test and iterate their automation tooling have this duplicated logic in many duplicate place. Solving this would be to move it to a single source, thus many people think NetBox, but maybe its another layer between NetBox and all their tooling.

Nautobot has something similar, and I'm not sure how utilized the feature is. What I think this comes down to, as with all other features is ROI. The ROI to implement and maintain long-term just may not be feasible at this time or at all. I just figured I bubble this feature up since I have heard some people ask about it recently.

[cameronw1996]

• 1 vote for me. I could see a use case where we can show specific custom fields dependant on what is entered into other fields for example device types. I.e if the device is a wireless access points then custom fields SSID and password would show.

[jeremystretch]

I could see a use case where we can show specific custom fields dependant on what is entered into other fields for example device types.

@cameronw1996 I don't believe that's what's being proposed here. This FR pertains to generating a specific value within a single custom field. All custom fields assigned to a model will always be displayed, and that's not something we would want to change (for several reasons).

[jeremystretch]

Would not the same scenario be possible for any custom field that a client references and is changed on the fly by an admin. IE the name of the field, the data type, or just the value someone might be keying on in their scrip/app.

Yes, but these changes can be inferred from the custom field itself, allowing the client to adapt if necessary. Not so with an arbitrary template.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

[ITJamie]

I would also like to see this feature. similar to the custom-link setup.

A few usecases.

• Getting data from other models eg prefixes and displaying it on an ip page
• Calculating information about an object and displaying it (eg subnet mask or gateways for an ip)

It could also be used as a workaround to displaying relationships to foreignkey plugin models. eg for prefixes on the access-lists demo plugin you could have a custom field that looks for related access list rules and return an array of id's

[ryanmerolle]

It could also be used as a workaround to displaying relationships to foreignkey plugin models. eg for prefixes on the access-lists demo plugin you could have a custom field that looks for related access list rules and return an array of id's.

Custom foreign keys sound like #7006 which was just released in 3.2.0