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

Enlarge DeviceType 'model' field to 100 chars #898

New Issue
Closed
opened 2025-12-29 16:26:49 +01:00 by adam · 5 comments
adam commented 2025-12-29 16:26:49 +01:00
Owner
Copy Link

Originally created by @cimnine on GitHub (May 2, 2017).

Issue type: Feature Request

The 'model' field of the DeviceType is currently limited to 50 characters. Could you extend the length of it to 100 chars?

In our current system, from which we want to migrate to Netbox, we have some device type identifier that are 77 chars long. We would like to preserve the current types for the time being.

Originally created by @cimnine on GitHub (May 2, 2017). ### Issue type: Feature Request The 'model' field of the DeviceType is currently limited to 50 characters. Could you extend the length of it to 100 chars? In our current system, from which we want to migrate to Netbox, we have some device type identifier that are 77 chars long. We would like to preserve the current types for the time being.
adam closed this issue 2025-12-29 16:26:49 +01:00
adam commented 2025-12-29 16:26:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 2, 2017):

The model field is intended to hold only the model name/number of a device. If you need more than 50 characters for this I'd wager you're misusing the field. Can you provide an example of a 77-character model name?

@jeremystretch commented on GitHub (May 2, 2017): The `model` field is intended to hold only the model name/number of a device. If you need more than 50 characters for this I'd wager you're misusing the field. Can you provide an example of a 77-character model name?
adam commented 2025-12-29 16:26:49 +01:00
Author
Owner
Copy Link

@cimnine commented on GitHub (May 2, 2017):

That'd probably be this one:

(HiddenABCDEF Network-Storage) Dual Xeon E5-2630Lv2 - R2312GZ4GC [cephbackup]`

That translates as follows:

(Purpose) CPU-Configuration - Model Type [special_purpose]

It's indeed a lot of information in there. And we're not proud of it, trust me on this. Yet we still have some tooling that depends on this information. That's why we want to stick to that scheme for the time being.

I'd argue that the change does not impact performance and that there are no other drawbacks, other than it doesn't look perfect in the respective dropdown and we're not behaving 'nicely' here.

@cimnine commented on GitHub (May 2, 2017): That'd probably be this one: (HiddenABCDEF Network-Storage) Dual Xeon E5-2630Lv2 - R2312GZ4GC [cephbackup]` That translates as follows: (Purpose) CPU-Configuration - Model Type [special_purpose] It's indeed a lot of information in there. And we're not proud of it, trust me on this. Yet we still have some tooling that depends on this information. That's why we want to stick to that scheme for the time being. I'd argue that the change does not impact performance and that there are no other drawbacks, other than it doesn't look perfect in the respective dropdown and we're not behaving 'nicely' here.
adam commented 2025-12-29 16:26:50 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 2, 2017):

The function of the device is irrelevant to its hardware definition. You wouldn't, for instance, create these two device types:

  • Juniper EX4300-48T (public switch)
  • Juniper EX4300-48T (private switch)

You'd just create one device type (Juniper EX4300-48T) and assign the appropriate roles to the individual devices.

I'd argue that the change does not impact performance and that there are no other drawbacks, other than it doesn't look perfect in the respective dropdown and we're not behaving 'nicely' here.

The field length limits were chosen specifically to discourage people from misusing the data model.

@jeremystretch commented on GitHub (May 2, 2017): The function of the device is irrelevant to its hardware definition. You wouldn't, for instance, create these two device types: * Juniper EX4300-48T (public switch) * Juniper EX4300-48T (private switch) You'd just create one device type (Juniper EX4300-48T) and assign the appropriate roles to the individual devices. > I'd argue that the change does not impact performance and that there are no other drawbacks, other than it doesn't look perfect in the respective dropdown and we're not behaving 'nicely' here. The field length limits were chosen specifically to discourage people from misusing the data model.
adam commented 2025-12-29 16:26:50 +01:00
Author
Owner
Copy Link

@cimnine commented on GitHub (May 2, 2017):

The thing is, that we derivate the hardware configuration based on the usage type. For example a ceph node has a lot of storage, whereas a compute node has a loads of RAM. Yet they both have the same chassis type.

@cimnine commented on GitHub (May 2, 2017): The thing is, that we derivate the hardware configuration based on the usage type. For example a ceph node has a lot of storage, whereas a compute node has a loads of RAM. Yet they both have the same chassis type.
adam commented 2025-12-29 16:26:50 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 2, 2017):

In that case, it seems like Model Type (Purpose) would suffice. You can keep additional information concerning the device type in its comments, or create a custom field.

@jeremystretch commented on GitHub (May 2, 2017): In that case, it seems like `Model Type (Purpose)` would suffice. You can keep additional information concerning the device type in its comments, or create a custom field.
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#898
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?