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

Add support for a status field on racks #1736

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

Originally created by @yarnocobussen on GitHub (May 22, 2018).

Issue type

[ X ] Feature request
[ ] Bug report
[ ] Documentation

Environment

  • Python version: 3.5.3
  • NetBox version: 2.3.3

Description

  • A detailed description of the proposed functionality
    Adding support for a status field on racks for the purpose of capacity management and tenant administration.

  • A use case for the new feature
    For our colocation services we do not only rent out space within a rack, but also racks as a whole.
    For us a rack can have 3 statuses. These seem quite universal throughout the colocation business:

  • Active (tenant is renting the rack)
  • Reserved (tenant is not renting the rack, but has a priority reservation for it)
  • Deprecated (tenant is renting the rack, but is in the process of moving out of it)

With these 3 statuses, we manage capacity and billing for colocation in our current (internal) tool. For capacity we use a dummy tenant and a reserved status to marks racks as available for real tenants. For billing purposes each status has a cost associated with it in our billing software. (which it reads by API) In Netbox, a fourth status with the type "Available" would make this even easier, although that may deviate to much from the status options in the rest of Netbox (?).

If implemented into Netbox, a status field for racks would significantly help us in our migration. I'm sure others are in a similar spot and would be able to make use of this as well. Also, we cannot see a way to make this work with /dcim/rack-reservations/, as it does not apply to entire racks and thus we cannot count how many racks with status X a tenant has.

  • A rough description of any necessary changes to the database schema
    This field already exists for other objects and I can't think of any conflicts with other functionality in Netbox. I guess it would simply mean adding a single column?

  • Any relevant third-party libraries which would be needed
    None

Originally created by @yarnocobussen on GitHub (May 22, 2018). ### Issue type [ X ] Feature request [ ] Bug report [ ] Documentation ### Environment * Python version: 3.5.3 * NetBox version: 2.3.3 ### Description * A detailed description of the proposed functionality Adding support for a status field on racks for the purpose of capacity management and tenant administration. * A use case for the new feature For our colocation services we do not only rent out space within a rack, but also racks as a whole. For us a rack can have 3 statuses. These seem quite universal throughout the colocation business: - Active (tenant is renting the rack) - Reserved (tenant is not renting the rack, but has a priority reservation for it) - Deprecated (tenant is renting the rack, but is in the process of moving out of it) With these 3 statuses, we manage capacity and billing for colocation in our current (internal) tool. For capacity we use a dummy tenant and a reserved status to marks racks as available for real tenants. For billing purposes each status has a cost associated with it in our billing software. (which it reads by API) In Netbox, a fourth status with the type "Available" would make this even easier, although that may deviate to much from the status options in the rest of Netbox (?). If implemented into Netbox, a status field for racks would significantly help us in our migration. I'm sure others are in a similar spot and would be able to make use of this as well. Also, we cannot see a way to make this work with /dcim/rack-reservations/, as it does not apply to entire racks and thus we cannot count how many racks with status X a tenant has. * A rough description of any necessary changes to the database schema This field already exists for other objects and I can't think of any conflicts with other functionality in Netbox. I guess it would simply mean adding a single column? * Any relevant third-party libraries which would be needed None
adam added the status: acceptedtype: feature labels 2025-12-29 16:34:52 +01:00
adam closed this issue 2025-12-29 16:34:52 +01:00
adam commented 2025-12-29 16:34:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 7, 2018):

We can try to get this in v2.4, however community feedback is required to solidify the exact set of rack status choices. I would suggest:

  1. Active
  2. Planned
  3. Reserved
  4. Deprecated
@jeremystretch commented on GitHub (Jun 7, 2018): We can try to get this in v2.4, however community feedback is required to solidify the exact set of rack status choices. I would suggest: 1. Active 2. Planned 3. Reserved 4. Deprecated
adam commented 2025-12-29 16:34:53 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Jun 7, 2018):

I like the idea, but what would the transition be like when moving between from "Deprecated" (from one tenant moving out) and another tenant moving in? Perhaps "Available" would work?

Although, just those statuses might be confusing for those who don't make use of tenants. Maybe also add an "In Use" too?

Would the following work:

  1. Available
  2. In Use (from "Active" in the above scenario)
  3. Planned
  4. Reserved
  5. Deprecated
@bdlamprecht commented on GitHub (Jun 7, 2018): I like the idea, but what would the transition be like when moving between from "Deprecated" (from one `tenant` moving out) and another `tenant` moving in? Perhaps "Available" would work? Although, just those statuses might be confusing for those who don't make use of `tenants`. Maybe also add an "In Use" too? Would the following work: 1. Available 2. In Use (from "Active" in the above scenario) 3. Planned 4. Reserved 5. Deprecated
adam commented 2025-12-29 16:34:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 7, 2018):

I'd avoid getting too granular. Tenancy should be managed separately from status. For example, you can have a rack that is planned, active, or reserved, and in any of these states may or may not be assigned a tenant.

@jeremystretch commented on GitHub (Jun 7, 2018): I'd avoid getting too granular. Tenancy should be managed separately from status. For example, you can have a rack that is planned, active, or reserved, and in any of these states may or may not be assigned a tenant.
adam commented 2025-12-29 16:34:53 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Jun 7, 2018):

Yeah, good point about granularity.
I suppose the FR just made me think too much. 🤔

I retract my above comment and go with yours.

@bdlamprecht commented on GitHub (Jun 7, 2018): Yeah, good point about granularity. I suppose the FR just made me think too much. :thinking: I retract my above comment and go with yours.
adam commented 2025-12-29 16:34:53 +01:00
Author
Owner
Copy Link

@yarnocobussen commented on GitHub (Jun 7, 2018):

The problem is that a rack is physical and can simply exist, without purpose and without plans for it.
The same goes for devices. For those, Netbox has a 6th status named inventory. This works nicely.
Since the inventory state for devices is already in Netbox, I suggest a similar status for racks:

  1. Active
  2. Planned
  3. Reserved
  4. Deprecated
  5. Inventory (Or Available, any word that gets the job done, really)

This is tenant neutral and covers all operational states I can think of. What do you guys think?

@yarnocobussen commented on GitHub (Jun 7, 2018): The problem is that a rack is physical and can simply exist, without purpose and without plans for it. The same goes for devices. For those, Netbox has a 6th status named inventory. This works nicely. Since the inventory state for devices is already in Netbox, I suggest a similar status for racks: 1. Active 2. Planned 3. Reserved 4. Deprecated 5. Inventory (Or Available, any word that gets the job done, really) This is tenant neutral and covers all operational states I can think of. What do you guys think?
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#1736
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?