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

Remove unique naming requirement for racks #411

New Issue
Closed
opened 2025-12-29 16:21:46 +01:00 by adam · 6 comments
adam commented 2025-12-29 16:21:46 +01:00
Owner
Copy Link

Originally created by @ajleach on GitHub (Sep 1, 2016).

This may be more of a feature request, and I apologize if this has been covered before.

We have multiple Sites, and at each site we have similar naming schemes - Site A and Site B both have similar layouts, so the Rack in Row A, Position 1 will have a name of A1. However, we're not able to name the rack at this location the same in both sites, as Netbox requires a unique name for each rack even when in different sites. Is there any way to use unique IDs for each rack behind the scenes so that we can name the racks whatever we'd like, or is this restriction intentional?

We have noticed the same thing for Devices. For example, we have two patch panels named the same thing, however they are located in two different racks.

Originally created by @ajleach on GitHub (Sep 1, 2016). This may be more of a feature request, and I apologize if this has been covered before. We have multiple Sites, and at each site we have similar naming schemes - Site A and Site B both have similar layouts, so the Rack in Row A, Position 1 will have a name of A1. However, we're not able to name the rack at this location the same in both sites, as Netbox requires a unique name for each rack even when in different sites. Is there any way to use unique IDs for each rack behind the scenes so that we can name the racks whatever we'd like, or is this restriction intentional? We have noticed the same thing for Devices. For example, we have two patch panels named the same thing, however they are located in two different racks.
adam added the status: duplicate label 2025-12-29 16:21:46 +01:00
adam closed this issue 2025-12-29 16:21:46 +01:00
adam commented 2025-12-29 16:21:47 +01:00
Author
Owner
Copy Link

@aoyawale commented on GitHub (Sep 2, 2016):

We have run into the same problem. For the moment, our work around has been adding the application in front of the hostname. EX. nginx rofl_nginx.dude.com

@aoyawale commented on GitHub (Sep 2, 2016): We have run into the same problem. For the moment, our work around has been adding the application in front of the hostname. EX. nginx rofl_nginx.dude.com
adam commented 2025-12-29 16:21:47 +01:00
Author
Owner
Copy Link

@iamdadmin commented on GitHub (Sep 2, 2016):

What version are you running? v1.5.2 here and I've got two racks in different sites with the same name.

@iamdadmin commented on GitHub (Sep 2, 2016): What version are you running? v1.5.2 here and I've got two racks in different sites with the same name.
adam commented 2025-12-29 16:21:47 +01:00
Author
Owner
Copy Link

@ajleach commented on GitHub (Sep 2, 2016):

@marvnrawley You're correct, I misunderstood what my network engineer was trying to do. It's actually within different rack groups in the same site that we're trying to have racks of the same name. Basically our 'sites' represent buildings, and 'rack groups' represent different rooms within that building (we basically have modular data centers). Were groups not intended to be used like this? Or is there a better way to accomplish what we're trying to do?

@ajleach commented on GitHub (Sep 2, 2016): @marvnrawley You're correct, I misunderstood what my network engineer was trying to do. It's actually within different rack groups in the same site that we're trying to have racks of the same name. Basically our 'sites' represent buildings, and 'rack groups' represent different rooms within that building (we basically have modular data centers). Were groups not intended to be used like this? Or is there a better way to accomplish what we're trying to do?
adam commented 2025-12-29 16:21:48 +01:00
Author
Owner
Copy Link

@iamdadmin commented on GitHub (Sep 2, 2016):

For racks, there is no reason you couldn't have more than one site group. For example, I have also aligned rack groups with the comms room / data hall, but you could be more granular and name your site group for the cage/area within the data hall. So instead of just "Comms room 2" you could name your group "Comms room 2 Cage 1".

Equally, try assigning the duplicate CIs to two separate tenants, it might allow you to overlap names then?

Granted these are not suggestions for fixes. I personally think that unique rack names and unique device names is the way to go, and the data we are putting in is already compliant with that.

Perhaps you could make a case here for nested rack groups however so you can partition it down further.

For example, you might want to have your site as a building, your building might have multiple floors, and each floor could have more than one comms room, or indeed your equipment might be in "Provider DC 2", "Hall 3", "Cage D08" and "Cage D11" - right now this is flattened to just site and group but it might be useful to support nesting or even just one extra layer of sub group.

@iamdadmin commented on GitHub (Sep 2, 2016): For racks, there is no reason you couldn't have more than one site group. For example, I have also aligned rack groups with the comms room / data hall, but you could be more granular and name your site group for the cage/area within the data hall. So instead of just "Comms room 2" you could name your group "Comms room 2 Cage 1". Equally, try assigning the duplicate CIs to two separate tenants, it might allow you to overlap names then? Granted these are not suggestions for fixes. I personally think that unique rack names and unique device names is the way to go, and the data we are putting in is already compliant with that. Perhaps you could make a case here for nested rack groups however so you can partition it down further. For example, you might want to have your site as a building, your building might have multiple floors, and each floor could have more than one comms room, or indeed your equipment might be in "Provider DC 2", "Hall 3", "Cage D08" and "Cage D11" - right now this is flattened to just site and group but it might be useful to support nesting or even just one extra layer of sub group.
adam commented 2025-12-29 16:21:48 +01:00
Author
Owner
Copy Link

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

This boils down to a trade-off between flexibility and convenience. If we allow multiple racks with the same name within a site, we can no longer refer to an individual rack by only its site and name; we would also need to specify its rack group, effectively requiring every rack to belong a rack group. This may or may not be acceptable.

@jeremystretch commented on GitHub (Sep 7, 2016): This boils down to a trade-off between flexibility and convenience. If we allow multiple racks with the same name within a site, we can no longer refer to an individual rack by only its site and name; we would also need to specify its rack group, effectively requiring every rack to belong a rack group. This may or may not be acceptable.
adam commented 2025-12-29 16:21:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 13, 2016):

Going to roll this into #238

@jeremystretch commented on GitHub (Sep 13, 2016): Going to roll this into #238
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: duplicate
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#411
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?