starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Increase length of "Custom Fields" #1749

New Issue
Closed
opened 2025-12-29 16:34:58 +01:00 by adam · 10 comments
adam commented 2025-12-29 16:34:58 +01:00
Owner
Copy Link

Originally created by @bdlamprecht on GitHub (May 25, 2018).

Issue type

[X] Feature request

Environment

  • Python version: 3.5.2
  • NetBox version: 2.3.3

Description

Currently, I have a "one-off" scenario where a certain platform (Juniper EX4550) has the need for a set of interfaces to be "trusted" for QoS purposes. The way my team is accomplishing this is within the groups section of the junos configuration (example below).

I was able to solve this problem by storing these values in a custom_field named special_attributes_1 and put JSON-formatted data in there. With the length of the field set to be 256, it worked just fine when I didn't have more than 16 interfaces to worry about.

However, I just came across some devices in our network with MORE than 16 interfaces that I need to account for.

The limit of 256 seems to be arbitrary. I understand the concern for not wanting to have custom_fields be a place to store TONS of information, but I think the current value seems to be quite small.

There would be no need to make any changes to the way it is displayed in the WebUI as I'm accessing it via the API. Simply increasing the length from 256 to 512 would be sufficient for my purposes as well as others who may need this for "one-off" scenarios as well.

Hopefully, this makes sense and I didn't stretch the limits of what you had in mind for custom_fields.
If you need additional information, please let me know.

The example from the group section of the configuration:
(with more than 16 interfaces that need to be "trusted")

trusted_links {
    firewall {
        family ethernet-switching {
            filter <*> {
                #
                # Trusted links - QoS class nc
                #
                term trusted_links_seq_10 { 
                        from { 
                            interface xe-0/0/0.0; 
                            interface xe-1/0/0.0; 
                            interface xe-0/0/3.0; 
                            interface xe-1/0/3.0; 
                            interface ge-0/0/5.0; 
                            interface ge-1/0/5.0; 
                            interface xe-0/0/19.0; 
                            interface xe-1/0/19.0; 
                            interface ge-0/0/11.0; 
                            interface ge-0/0/12.0; 
                            interface ge-0/0/13.0; 
                            interface ge-0/0/14.0; 
                            interface ge-0/0/15.0; 
                            interface ge-0/0/16.0; 
                            interface ge-0/0/17.0; 
                            interface ge-1/0/11.0; 
                            interface ge-1/0/12.0; 
                            interface ge-1/0/13.0; 
                            interface ge-1/0/16.0; 
                            interface ge-1/0/17.0; 
                            interface xe-0/0/2.0; 
                            interface xe-1/0/2.0; 
                            interface ge-0/0/4.0; 
                            dscp [ cs6 cs7 ]; 
                        } 
                        then { 
                            accept; 
                            forwarding-class nc; 
                            loss-priority low; 
                        }

Screenshot of how I'm currently solving this in NetBox:
image

Originally created by @bdlamprecht on GitHub (May 25, 2018). ### Issue type [X] Feature request <!-- An enhancement of existing functionality --> ### Environment * Python version: 3.5.2 * NetBox version: 2.3.3 ### Description Currently, I have a "one-off" scenario where a certain platform (Juniper EX4550) has the need for a set of interfaces to be "trusted" for QoS purposes. The way my team is accomplishing this is within the `groups` section of the `junos` configuration (example below). I was able to solve this problem by storing these values in a `custom_field` named `special_attributes_1` and put JSON-formatted data in there. With the length of the field set to be `256`, it worked just fine when I didn't have more than 16 interfaces to worry about. However, I just came across some devices in our network with **MORE** than 16 interfaces that I need to account for. The limit of `256` _seems_ to be arbitrary. I understand the concern for not wanting to have `custom_fields` be a place to store TONS of information, but I think the current value seems to be quite small. There would be no need to make any changes to the way it is displayed in the WebUI as I'm accessing it via the API. Simply increasing the length from `256` to `512` would be sufficient for my purposes as well as others who may need this for "one-off" scenarios as well. Hopefully, this makes sense and I didn't stretch the limits of what you had in mind for `custom_fields`. If you need additional information, please let me know. --- The example from the `group` section of the configuration: (with more than 16 interfaces that need to be "trusted") ``` trusted_links { firewall { family ethernet-switching { filter <*> { # # Trusted links - QoS class nc # term trusted_links_seq_10 { from { interface xe-0/0/0.0; interface xe-1/0/0.0; interface xe-0/0/3.0; interface xe-1/0/3.0; interface ge-0/0/5.0; interface ge-1/0/5.0; interface xe-0/0/19.0; interface xe-1/0/19.0; interface ge-0/0/11.0; interface ge-0/0/12.0; interface ge-0/0/13.0; interface ge-0/0/14.0; interface ge-0/0/15.0; interface ge-0/0/16.0; interface ge-0/0/17.0; interface ge-1/0/11.0; interface ge-1/0/12.0; interface ge-1/0/13.0; interface ge-1/0/16.0; interface ge-1/0/17.0; interface xe-0/0/2.0; interface xe-1/0/2.0; interface ge-0/0/4.0; dscp [ cs6 cs7 ]; } then { accept; forwarding-class nc; loss-priority low; } ``` --- Screenshot of how I'm currently solving this in NetBox: ![image](https://user-images.githubusercontent.com/7783306/40559048-aa4a8862-6012-11e8-9038-30accc64f297.png)
adam closed this issue 2025-12-29 16:34:58 +01:00
adam commented 2025-12-29 16:34:58 +01:00
Author
Owner
Copy Link

@pm17788 commented on GitHub (May 29, 2018):

@bdlamprecht: As a workaround, how about making these trusted links as inventory items attached to parent device?

It'll have the effect of cleaning up all the main page display view (cosmetic, certainly, but it's a a Something 😁 ), and, the Inventory Items are a multi-valued in that you can have multiple instances of an things with a part id trusted_link.

Another advantage is that you don't have to pack/parse/unpack a text field, but, rather, at API level, you'd query https://netbox/api/dcim/inventory-items/?part_id=trusted_link&device=JuniperEX4550 and get useful data (along with a count, for a cross-check) back? There's also a Description field to be leveraged there, which is useful in that you can feed all kinds of Usefulness into that, too?

@pm17788 commented on GitHub (May 29, 2018): @bdlamprecht: As a workaround, how about making these **trusted links** as inventory items attached to parent device? It'll have the effect of cleaning up all the main page display view (cosmetic, certainly, but it's a a _Something_ :grin: ), and, the `Inventory Items` are a multi-valued in that you can have multiple instances of an things with a part id `trusted_link`. Another advantage is that you don't have to pack/parse/unpack a text field, but, rather, at API level, you'd query https://netbox/api/dcim/inventory-items/?part_id=trusted_link&device=JuniperEX4550 and get useful data (along with a count, for a cross-check) back? There's also a Description field to be leveraged there, which is useful in that you can feed all kinds of Usefulness into that, too?
adam commented 2025-12-29 16:34:58 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (May 29, 2018):

@pm17788 At first I didn't understand what you were referring to, but now I think I have an understanding of what you are trying to communicate. That being said, these "trusted links" are not really (from the NetBox documentation) separate hardware components, but instead, are a logical configuration of the switch chassis.

I like the core idea of NetBox being to document and define how things are supposed to be, and not try and cram things where ever we want them to be just because we can. Using custom fields (I believe) is an appropriate location for this one-off scenario, but I'm limited to the 255-character limit. I'd just like the size of the field to be somewhat larger.

Thanks for the thought though.

@bdlamprecht commented on GitHub (May 29, 2018): @pm17788 At first I didn't understand what you were referring to, but now I **_think_** I have an understanding of what you are trying to communicate. That being said, these "**trusted links**" are not really (from the NetBox documentation) [separate hardware components](http://netbox.readthedocs.io/en/latest/data-model/dcim/#inventory-items), but instead, are a logical configuration of the switch chassis. I like the core idea of NetBox being to document and define how things **are supposed to be**, and not try and cram things where ever we want them to be just because we can. Using **custom fields** (I believe) is an appropriate location for this _one-off_ scenario, but I'm limited to the 255-character limit. I'd just like the size of the field to be _somewhat_ larger. Thanks for the thought though.
adam commented 2025-12-29 16:34:59 +01:00
Author
Owner
Copy Link

@pm17788 commented on GitHub (May 29, 2018):

@bdlamprecht: Fair enough :) Sorry for being unclear. Workarounds are... yeah, well, workarounds :)

@pm17788 commented on GitHub (May 29, 2018): @bdlamprecht: Fair enough :) Sorry for being unclear. Workarounds are... yeah, well, workarounds :)
adam commented 2025-12-29 16:34:59 +01:00
Author
Owner
Copy Link

@pm17788 commented on GitHub (May 30, 2018):

As a thought, what about having a flag on a custom field which would hide it from the UI view? Still present via API, though.
I find that I have users who just want the WebUI, and for them, an overabundance of custom fields is confusing (especially those which are packed for machine-parseability). The API users I basically don't care about in that if they're using the API, it's on them to filter stuff they don't want to see .

(Edited to explain the rationale)

@pm17788 commented on GitHub (May 30, 2018): As a thought, what about having a flag on a custom field which would hide it from the UI view? Still present via API, though. I find that I have users who just want the WebUI, and for them, an overabundance of custom fields is confusing (especially those which are packed for machine-parseability). The API users I basically don't care about in that if they're using the API, it's on them to filter stuff they don't want to see <GRIN>. (Edited to explain the rationale)
adam commented 2025-12-29 16:34:59 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (May 30, 2018):

Thanks for the suggestion. Perhaps that could be an option as well, but for me personally, I find it confusing when the WebUI and the API don't match (although I could be the minority in that regard).
That being said, I'd like to not mix up requests so if you're wanting that feature, I'd suggest opening a separate issue using the wording you just described.

Cheers.

@bdlamprecht commented on GitHub (May 30, 2018): Thanks for the suggestion. Perhaps that could be an option as well, but for me personally, I find it confusing when the WebUI and the API don't match (although I could be the minority in that regard). That being said, I'd like to not mix up requests so if you're wanting that feature, I'd suggest opening a separate issue using the wording you just described. Cheers.
adam commented 2025-12-29 16:34:59 +01:00
Author
Owner
Copy Link

@1tsi commented on GitHub (Jun 26, 2018):

I just stumbled upon the same kind of problem today with virtual machines, unfortunately there is no such option.
It would be great to have custom text fields with an increased text length.

Best Regards

@1tsi commented on GitHub (Jun 26, 2018): I just stumbled upon the same kind of problem today with virtual machines, unfortunately there is no such option. It would be great to have custom text fields with an increased text length. Best Regards
adam commented 2025-12-29 16:34:59 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 2, 2018):

The limit of 256 seems to be arbitrary. I understand the concern for not wanting to have custom_fields be a place to store TONS of information, but I think the current value seems to be quite small.

Yes, that's been the goal from the beginning. Custom fields are a convenience allowing you to store a single, small, unique value per field per object. They are not intended to replace a proper templating system or database. Some surefire signs that you're abusing custom fields include trying to set multiple values per field, or setting the same value for all objects in a set.

I encourage you to look into context config data (#1349), which will be available in v2.4. It should fit your particular use case much better.

@jeremystretch commented on GitHub (Jul 2, 2018): > The limit of 256 seems to be arbitrary. I understand the concern for not wanting to have custom_fields be a place to store TONS of information, but I think the current value seems to be quite small. Yes, that's been the goal from the beginning. Custom fields are a convenience allowing you to store a single, small, *unique* value per field per object. They are **not** intended to replace a proper templating system or database. Some surefire signs that you're abusing custom fields include trying to set multiple values per field, or setting the same value for all objects in a set. I encourage you to look into context config data (#1349), which will be available in v2.4. It should fit your particular use case much better.
adam commented 2025-12-29 16:34:59 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Jul 2, 2018):

Yes, I'm aware of #1349 as I'm the one who first opened it and have been waiting axiously for it being implemented (BTW, thanks a ton for getting that working, I haven't had the chance to look into it just yet, but will shortly).

However, I'd like to point out that the use-case scenario for this json data being stored in this custom_field is in fact a "unqiue value per field per object" and, unfortunately, due to circumstances outside of my control (i.e. customer requirements and vendor stupidity within the same family of switches), I cannot templatize them any more than I already have.

Also, concerning this statement:

Some surefire signs that you're abusing custom fields include trying to set multiple values per field, or setting the same value for all objects in a set.

Just for some background explanation on the use-case for this FR, this is for a switch "template" that has any port within the range of [ge|xe]-0/0/0 to [ge|xe]-0/0/18 and [ge|xe]-1/0/0 to [ge|xe]-1/0/18 (stack of switches) available to connect to equipment that MAY or may NOT support the QoS markings that we require within our realm of management (i.e. trusted or not trusted).

My intention is not to be argumentative in any way and I understand that the line has to be drawn somewhere, however, I feel that a limit of 256 is still quite low and would like to ask that you take another look at expanding that field slightly.

@bdlamprecht commented on GitHub (Jul 2, 2018): Yes, I'm aware of #1349 as I'm the one who first opened it and have been waiting axiously for it being implemented (BTW, thanks a ton for getting that working, I haven't had the chance to look into it just yet, but will shortly). However, I'd like to point out that the use-case scenario for this `json` data being stored in this `custom_field` is in fact a "_unqiue_ value per field per object" and, unfortunately, due to circumstances outside of my control (i.e. customer requirements and vendor stupidity within the same family of switches), I cannot templatize them any more than I already have. Also, concerning this statement: > Some surefire signs that you're abusing custom fields include trying to set multiple values per field, or setting the same value for all objects in a set. Just for some background explanation on the use-case for this FR, this is for a switch "template" that has any port within the range of `[ge|xe]-0/0/0` to `[ge|xe]-0/0/18` and `[ge|xe]-1/0/0` to `[ge|xe]-1/0/18` (stack of switches) available to connect to equipment that **MAY** or may **NOT** support the QoS markings that we require within our realm of management (i.e. trusted or not trusted). My intention is not to be argumentative in any way and I understand that the line has to be drawn somewhere, however, I feel that a limit of `256` is still quite low and would like to ask that you take another look at expanding that field _slightly_.
adam commented 2025-12-29 16:35:00 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 2, 2018):

Yes, I'm aware of #1349 as I'm the one who first opened it

Derp. Right, sorry. I've just gotten so used to referring people to it.

My intention is not to be argumentative in any way and I understand that the line has to be drawn somewhere, however, I feel that a limit of 256 is still quite low and would like to ask that you take another look at expanding that field slightly.

The thing is, that's how scope creep works. It's always a slight change, followed by another slight change, and then another and another. NetBox was built to serve as an IPAM/DCIM application, which is already ill-defined territory, and there's constant demand to extend it in myriad directions to fulfill other functions.

@jeremystretch commented on GitHub (Jul 2, 2018): > Yes, I'm aware of #1349 as I'm the one who first opened it Derp. Right, sorry. I've just gotten so used to referring people to it. > My intention is not to be argumentative in any way and I understand that the line has to be drawn somewhere, however, I feel that a limit of `256` is still quite low and would like to ask that you take another look at expanding that field _slightly_. The thing is, that's how scope creep works. It's always a _slight_ change, followed by another _slight_ change, and then another and another. NetBox was built to serve as an IPAM/DCIM application, which is already ill-defined territory, and there's constant demand to extend it in myriad directions to fulfill other functions.
adam commented 2025-12-29 16:35:00 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Jul 2, 2018):

Yeah, scope creep is nasty to deal with and is why I said:

I understand the line has to be drawn somewhere

I'll see what kind of hacks using duct-tape and bailing-wire I can create to solve the problem.
I appreciate all of what you've done in creating NetBox and getting it to where it is now.

Cheers!

@bdlamprecht commented on GitHub (Jul 2, 2018): Yeah, scope creep is nasty to deal with and is why I said: >I understand the line has to be drawn somewhere I'll see what kind of hacks using duct-tape and bailing-wire I can create to solve the problem. I appreciate all of what you've done in creating NetBox and getting it to where it is now. Cheers!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#1749
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?