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

Racks with units starting > 1 #7863

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

Originally created by @bebehei on GitHub (Apr 5, 2023).

Originally assigned to: @arthanson on GitHub.

NetBox version

87e7cc4867d1 (v3.4.6)

Feature type

Data model extension

Proposed functionality

Currently, it is possible to assign a rack an arbitrary number of height units (usually 42 or 47). The starting point is fixed to 1, so all Devices in this Rack are located in RU {1..Y}.

This GitHub issue requests, that the starting point does not start hard coded from 1.

Use case

If you rent a quarter half/quarter/third rack, the starting point is not fixed necessarily fixed to Rack Unit 1. To talk to remote hands, this is quite confusing.

Current possible workarounds:

  • You could currently work around by creating a full rack and assigning Rack Reservations.
    • CON: This will falsely blow up the actual space utilisation of your rack. (e.g. quarter rack used with 2 Rack units displays 80% Rack Usage, while actually only 10% are used.)
  • Assign the rack the actual height and use instead of 41-60 the units 1-20.
    • CON: You have to convert this when talking to remote hands (error prone).
    • CON: Rack Photos show the actual rack unit and not the virtual unit
  • Tenancy should be a possibilty, but I haven't found anything to work around this with tenancy.

Database changes

No response

External dependencies

No response

Originally created by @bebehei on GitHub (Apr 5, 2023). Originally assigned to: @arthanson on GitHub. ### NetBox version 87e7cc4867d1 (v3.4.6) ### Feature type Data model extension ### Proposed functionality Currently, it is possible to assign a rack an arbitrary number of height units (usually 42 or 47). The starting point is fixed to `1`, so all Devices in this Rack are located in RU `{1..Y}`. This GitHub issue requests, that the starting point does not start hard coded from 1. ### Use case If you rent a quarter half/quarter/third rack, the starting point is not fixed necessarily fixed to Rack Unit 1. To talk to remote hands, this is quite confusing. Current possible workarounds: - You could currently work around by creating a full rack and assigning Rack Reservations. - CON: This will falsely blow up the actual space utilisation of your rack. (e.g. quarter rack used with 2 Rack units displays 80% Rack Usage, while actually only 10% are used.) - Assign the rack the actual height and use instead of 41-60 the units 1-20. - CON: You have to convert this when talking to remote hands (error prone). - CON: Rack Photos show the actual rack unit and not the virtual unit - Tenancy should be a possibilty, but I haven't found anything to work around this with tenancy. ### Database changes _No response_ ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 20:29:08 +01:00
adam closed this issue 2025-12-29 20:29:08 +01:00
adam commented 2025-12-29 20:29:09 +01:00
Author
Owner
Copy Link

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

It sounds like adding a starting_unit integer field (defaulting to 1) to the Rack model would suffice. We'd no doubt have to dig through a lot of logic that assumes a starting unit of 1, but it should be feasible.

@jeremystretch commented on GitHub (May 4, 2023): It sounds like adding a `starting_unit` integer field (defaulting to 1) to the Rack model would suffice. We'd no doubt have to dig through a lot of logic that assumes a starting unit of 1, but it should be feasible.
adam commented 2025-12-29 20:29:09 +01:00
Author
Owner
Copy Link

@bebehei commented on GitHub (Jun 23, 2023):

Thank you all for adding this feature!

@bebehei commented on GitHub (Jun 23, 2023): Thank you all for adding this feature!
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 status: accepted 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#7863
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?