Expose Custom Fields via API

[adamwoolhether]

Environment

• Python version: 3.6.8
• NetBox version: 2.9.7

Proposed Functionality

Currently, Custom Fields can only be added/modified through the Admin console. A Custom Fields plugin cannot be implemented for Netbox's Ansible modules until Custom fields are exposed via API (see: netbox-community/ansible_modules#335)

We use a lot of custom modules to keep track of an individual machine's internal hardware for inventory tracking, Exposing custom modules via API would allow more efficient management of custom fields.

Use Case

Configure, create, and manage custom fields without having to login to Netbox's web UI Admin console would further increase the ability to manage the environment through Ansible.

I work for a large HW manufacturer, and rather than managing a single Netbox env, we potentially deploy different Netbox environments for a specific isolated department, team, or different customers. We utilize anywhere from 10-15 different custom fields for each, and input the values with information extracted from the machine itself(ex: CPU type, amt, Interface MAC, GPU etc).

We automatically install, setup, and conduct initial data-population via ansible playbooks. Each time, however, requires manual intervention between steps 2 & 3, to create the custom fields from within the Netbox UI.

Database Changes

Forgive me, this is not my area of expertise and I can't offer any relevant information...

External Dependencies

No new external dependencies should be required.

[jeremystretch]

Configure, create, and manage custom fields without having to login to Netbox's web UI Admin console would further increase the ability to manage the environment through Ansible.

You've described the functionality being proposed, but could you expand on your specific use case? Custom fields are intended to serve as long-term attributes used to extend select models in a specific way: They don't typically change much beyond initial creation, and it's difficult to imagine a case where creating new fields using a tool such as Ansible makes sense.

[arjenvri]

I am having the same need, in our case the use case is running Netbox in a CI/CD environment where all Netbox configuration is managed by code and redeployed frequently.

[adamwoolhether]

Configure, create, and manage custom fields without having to login to Netbox's web UI Admin console would further increase the ability to manage the environment through Ansible.

You've described the functionality being proposed, but could you expand on your specific use case? Custom fields are intended to serve as long-term attributes used to extend select models in a specific way: They don't typically change much beyond initial creation, and it's difficult to imagine a case where creating new fields using a tool such as Ansible makes sense.

Hi @jeremystretch . Definitely. I work for a large HW manufacturer, and rather than managing a single Netbox env, we potentially deploy different Netbox environments for a specific isolated department, team, or different customers. We utilize anywhere from 10-15 different custom fields for each, and input the values with information extracted from the machine itself(ex: CPU type, amt, Interface MAC, GPU etc).

We automatically install, setup, and conduct initial data-population via ansible playbooks. Each time, however, requires manual intervention between steps 2 & 3, to create the custom fields from within the Netbox UI.

You're correct, they don't change much beyond creation, but creating many different environments with 10+ custom fields greatly impacts the deployment speed.

[jeremystretch]

We might actually have to push this up to v2.10. As part of the overhaul under #4878, the current /api/extras/_custom_field_choices/ REST API endpoint was removed. While we could reproduce its output under the new model, doing so certainly feels like a kludge given that all choices are now stored within CustomField instances. It's probably best just to push forward with adding REST API support for custom fields to avoid losing any functionality.

I don't yet have a good idea how much work this will entail or by how long it might delay the final v2.10 release.

[jeremystretch]

Went ahead with this in the current develop-2.10 branch. Might push out a second 2.10 beta to capture it for further testing soon.