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 facility name length to >50 chars #8912

New Issue
Closed
opened 2025-12-29 20:42:46 +01:00 by adam · 4 comments
adam commented 2025-12-29 20:42:46 +01:00
Owner
Copy Link

Originally created by @jwbensley on GitHub (Dec 4, 2023).

NetBox version

v3.5.9

Feature type

Change to existing functionality

Proposed functionality

Increase the facility name length to be more than 50 chars.

Use case

There are facilities with a name which is longer than 50 chars, we are unable to enter them into NetBox.

These are example facilities with names > 50 chars which we are interested in (there are more, and with even longer names, but we aren't interested in those facilities so I can't comment on them):

We obviously don't enter these by hand, we use the NetBox API so we can't easily shorten them. Also, if we modify the name, we then can't match it against other databases like PeeringDB.

Database changes

Sorry, I don't really know what's involved here.

External dependencies

Sorry, I'm not sure.

Originally created by @jwbensley on GitHub (Dec 4, 2023). ### NetBox version v3.5.9 ### Feature type Change to existing functionality ### Proposed functionality Increase the facility name length to be more than 50 chars. ### Use case There are facilities with a name which is longer than 50 chars, we are unable to enter them into NetBox. These are example facilities with names > 50 chars which we are interested in (there are more, and with even longer names, but we aren't interested in those facilities so I can't comment on them): * https://www.peeringdb.com/fac/4248 -> `Equinix SY7 - Sydney (formerly Metronode Illawara 1)` 52 chars * https://www.peeringdb.com/fac/274 -> `myLoc Datacenter DUS1, DUS2, DUS3, DUS4, DUS6, DUS7` 51 chars * https://www.peeringdb.com/fac/5922 -> `Equinix BR1 - Brisbane (formerly Metronode Brisbane 1)` 54 chars * https://www.peeringdb.com/fac/64 `Interxion Amsterdam Schiphol Campus (AMS3, AMS5, AMS6, AMS7, AMS8, AMS10)` 74 chars We obviously don't enter these by hand, we use the NetBox API so we can't easily shorten them. Also, if we modify the name, we then can't match it against other databases like PeeringDB. ### Database changes Sorry, I don't really know what's involved here. ### External dependencies Sorry, I'm not sure.
adam added the type: feature label 2025-12-29 20:42:46 +01:00
adam closed this issue 2025-12-29 20:42:47 +01:00
adam commented 2025-12-29 20:42:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 4, 2023):

Increase the facility name length to be more than 50 chars.

I assume you're referring to the facility_id field on the rack model, which is limited to 50 characters in length.

As is documented, this field is intended to represent a unique identifier assigned by the facility to the rack, as an alternative means of identification (in addition to the rack's locally-assigned name). (For example, what you refer to as "rack 204" might be referenced by the facility as NY7.FL2.0428.) It is not meant to store a site or facility name; that is the purpose of the site and location models to which a rack is assigned. As such, your use case above is invalid.

Also, if we modify the name, we then can't match it against other databases like PeeringDB.

Custom fields offer a great solution for cases like this where you need to replicate arbitrary external data.

@jeremystretch commented on GitHub (Dec 4, 2023): > Increase the facility name length to be more than 50 chars. I assume you're referring to the `facility_id` field on the rack model, which is limited to 50 characters in length. [As is documented](https://docs.netbox.dev/en/stable/models/dcim/rack/#facility-id), this field is intended to represent a unique identifier **assigned by the facility** to the rack, as an alternative means of identification (in addition to the rack's locally-assigned name). (For example, what you refer to as "rack 204" might be referenced by the facility as `NY7.FL2.0428`.) It is not meant to store a site or facility name; that is the purpose of the [site](https://docs.netbox.dev/en/stable/models/dcim/site/) and [location](https://docs.netbox.dev/en/stable/models/dcim/location/) models to which a rack is assigned. As such, your use case above is invalid. > Also, if we modify the name, we then can't match it against other databases like PeeringDB. [Custom fields](https://docs.netbox.dev/en/stable/customization/custom-fields/) offer a great solution for cases like this where you need to replicate arbitrary external data.
adam commented 2025-12-29 20:42:47 +01:00
Author
Owner
Copy Link

@jwbensley commented on GitHub (Dec 4, 2023):

Hi @jeremystretch I'm referring to the facility field when creating a site https://netbox-demo.netboxlabs.com/dcim/sites/add/

@jwbensley commented on GitHub (Dec 4, 2023): Hi @jeremystretch I'm referring to the facility field when creating a site https://netbox-demo.netboxlabs.com/dcim/sites/add/
adam commented 2025-12-29 20:42:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 4, 2023):

It's used in the same manner, to denote a unique ID assigned by the facility owner. All of your examples above include other information that should be stored in the site's name, description, or a custom field.

@jeremystretch commented on GitHub (Dec 4, 2023): It's used in the same manner, to denote a unique ID assigned by the facility owner. All of your examples above include other information that should be stored in the site's name, description, or a custom field.
adam commented 2025-12-29 20:42:48 +01:00
Author
Owner
Copy Link

@jwbensley commented on GitHub (Dec 4, 2023):

We store our name for the PoP in the site name field (it is very common for network network operators to have their own names for sites, which are often airport codes, or UN/LOCODEs, because they are standardised) and we store the name the data centre operator uses in the facility field.

Is this wrong, because that is exactly what is described in the documentation: https://docs.netbox.dev/en/stable/models/dcim/site/

Name
The site's unique name

Facility
Data center or facility designation for identifying the site.
@jwbensley commented on GitHub (Dec 4, 2023): We store our name for the PoP in the site name field (it is very common for network network operators to have their own names for sites, which are often airport codes, or UN/LOCODEs, because they are standardised) and we store the name the data centre operator uses in the facility field. Is this wrong, because that is exactly what is described in the documentation: https://docs.netbox.dev/en/stable/models/dcim/site/ ``` Name The site's unique name ``` ``` Facility Data center or facility designation for identifying the site. ```
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 type: feature
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#8912
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?