Support decimal rack/device height units #6940

New Issue

adam · 2025-12-29T19:47:02+01:00

adam commented

2025-12-29 19:47:02 +01:00

Originally created by @Toothwitch on GitHub (Sep 7, 2022).

NetBox version

v3.3.2

Feature type

Change to existing functionality

Proposed functionality

With v3.3 we got the possibility to use .5 rack units

As seen in the discussions/issue to this release there are voices to change this from .5 limit to fractions to be more flexible.
https://github.com/netbox-community/netbox/discussions/9727#discussioncomment-3258931
https://github.com/netbox-community/netbox/issues/51

For the api the only change would be to remove the .5 modulo validator.

See also:
https://github.com/netbox-community/netbox/issues/10271

Use case

As seen in the discussions the common rack has 3 rack mount units/holes. But there are even more rack types out there which probably could only be summarized with the common denominator .1
For example there may be some Cisco ASA5505 (.?), Brocade FastIron Edge GS (.3) or Juniper MX104 (.5) around.

Reality shows there is a need for more granularity as the existing datacenters will more than likely not be changed to accomodate the datamodel as of now.

Database changes

No response

External dependencies

No response

Originally created by @Toothwitch on GitHub (Sep 7, 2022). ### NetBox version v3.3.2 ### Feature type Change to existing functionality ### Proposed functionality With v3.3 we got the possibility to use .5 rack units As seen in the discussions/issue to this release there are voices to change this from .5 limit to fractions to be more flexible. https://github.com/netbox-community/netbox/discussions/9727#discussioncomment-3258931 https://github.com/netbox-community/netbox/issues/51 For the api the only change would be to remove the .5 modulo validator. See also: https://github.com/netbox-community/netbox/issues/10271 ### Use case As seen in the discussions the common rack has 3 rack mount units/holes. But there are even more rack types out there which probably could only be summarized with the common denominator .1 For example there may be some Cisco ASA5505 (.?), Brocade FastIron Edge GS (.3) or Juniper MX104 (.5) around. Reality shows there is a need for more granularity as the existing datacenters will more than likely not be changed to accomodate the datamodel as of now. ### Database changes _No response_ ### External dependencies _No response_

adam added the type: feature label 2025-12-29 19:47:02 +01:00

adam closed this issue

2025-12-29 19:47:02 +01:00

adam commented

2025-12-29 19:47:03 +01:00

@jeremystretch commented on GitHub (Sep 7, 2022):

I'm sorry, but the time to propose such a change was during the month-long v3.3 beta period preceding the release. I'm aware there was some discussion in the release thread, however no one submitted an actual proposal in the form of a detailed feature request (likely because of the challenges I describe below). As the release has passed, we're no longer considering any potentially breaking changes to the implementation.

For the api the only change would be to remove the .5 modulo validator.

This would be far more involved than that. #51 was implemented by essentially changing the atomic unit for rack space from 1U to 0.5U. What you're suggesting would require changing the atomic unit to 0.1U, which would be extremely unwieldy and greatly complicate the modeling of rack elevations, both visually and as conveyed via the APIs. I actually looked into this early on, and quickly decided against such a complicated scheme in favor of the more palatable approach we have in v3.3 that still addresses the vast majority of use cases.

@jeremystretch commented on GitHub (Sep 7, 2022): I'm sorry, but the time to propose such a change was during the month-long v3.3 beta period preceding the release. I'm aware there was some discussion in the release thread, however no one submitted an actual proposal in the form of a detailed feature request (likely because of the challenges I describe below). As the release has passed, we're no longer considering any potentially breaking changes to the implementation. > For the api the only change would be to remove the .5 modulo validator. This would be far more involved than that. #51 was implemented by essentially changing the atomic unit for rack space from 1U to 0.5U. What you're suggesting would require changing the atomic unit to 0.1U, which would be extremely unwieldy and greatly complicate the modeling of rack elevations, both visually and as conveyed via the APIs. I actually looked into this early on, and quickly decided against such a complicated scheme in favor of the more palatable approach we have in v3.3 that still addresses the vast majority of use cases.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#6940