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

Relax naming constraints for Devices #871

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

Originally created by @bellwood on GitHub (Apr 18, 2017).

Branching this off from #238

I'm running into issues where my real-world naming consistencies are not allowed within Netbox due to unique constraints.

Some background:

I have Site A -> Site C, each site has Zone 1 -> Zone 5, each zone has Rack 1 -> Rack 50, each rack has PDU-A -> PDU-B

The first issue I run into is that I cannot have two racks named R1 in a single site even though they are in separate rack groups.

As a result I have to preface it with the Zone, so R1 in Z1 becomes R101.

Next issue, devices, I cannot have multiple PDUs (rPDUS) called PDU-A and PDU-B, nor can I have multiple rack prefixed PDU's, R1-PDU-A.

As a result, I have to pre and post fix the name with a rack and zone: R1-PDU-A.Z1

Next issue, I cannot have the same devices names even if they are in different sites, R1-PDU-A.Z1 in site A cannot co-exist with R1-PDU-A.Z1 in site B, this not considered unique.

Why is this such a problem?

Well I have hostnames defined on our methodologies:

R#-PDU-#.Z#.SITE#.DOMAIN.TLD

With the advancements netbox is making, I'm already invisioning hacks beyond hacks to build the proper FQDN's to represent my physical world to interact.

It also means storing redundant data, like zone/rack, or irrelevant data, like rack zone prefixing.

Ideally:

Racks:
Rack-Slug.RackGroup-Slug.Site-Slug.DOMAIN.TLD

Devices:
DeviceName.RackGroup-Slug.Site-Slug.DOMAIN.TLD

Where in the uniquity is scoped to the rack group.

Originally created by @bellwood on GitHub (Apr 18, 2017). Branching this off from #238 I'm running into issues where my real-world naming consistencies are not allowed within Netbox due to unique constraints. Some background: I have Site A -> Site C, each site has Zone 1 -> Zone 5, each zone has Rack 1 -> Rack 50, each rack has PDU-A -> PDU-B The first issue I run into is that I cannot have two racks named R1 in a single site even though they are in separate rack groups. As a result I have to preface it with the Zone, so R1 in Z1 becomes R101. Next issue, devices, I cannot have multiple PDUs (rPDUS) called PDU-A and PDU-B, nor can I have multiple rack prefixed PDU's, R1-PDU-A. As a result, I have to pre and post fix the name with a rack and zone: R1-PDU-A.Z1 Next issue, I cannot have the same devices names even if they are in different sites, R1-PDU-A.Z1 in site A cannot co-exist with R1-PDU-A.Z1 in site B, this not considered unique. Why is this such a problem? Well I have hostnames defined on our methodologies: R#-PDU-#.Z#.SITE#.DOMAIN.TLD With the advancements netbox is making, I'm already invisioning hacks beyond hacks to build the proper FQDN's to represent my physical world to interact. It also means storing redundant data, like zone/rack, or irrelevant data, like rack zone prefixing. Ideally: Racks: Rack-Slug.RackGroup-Slug.Site-Slug.DOMAIN.TLD Devices: DeviceName.RackGroup-Slug.Site-Slug.DOMAIN.TLD Where in the uniquity is scoped to the rack group.
adam closed this issue 2025-12-29 16:26:31 +01:00
adam commented 2025-12-29 16:26:32 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 18, 2017):

The first issue I run into is that I cannot have two racks named R1 in a single site even though they are in separate rack groups.

This is covered by #238. Let's not duplicate the discussion here.

uniquity (word?)

Uniqueness 😄

Currently, NetBox requires each device to have either a unique name, or no name. The proposal to shrink the scope of uniqueness to a rack group is problematic because racks don't need to be assigned to rack groups, and devices don't even need to be assigned to racks. This leads to very complex validation logic because (AFAIK) we can't just use the unique_together Meta attribute to enforce uniqueness across multiple tables at the database level. It would be feasible to make device names unique per site, but I'm not sure how useful that would be.

The other problem is that, similar to #238, referencing a device by name now requires a tuple of (parent object name, device name). So importing interface connections, for example, would now require the user to first determine the site or rack in which every device exists. This is a substantial additional burden for users, especially those who employ only unique device names.

As a workaround, could you name the PDUs following the pattern R<rack>-PDU-[AB].<zone>.<site>? I understand it's not the ideal solution, but it seems like it would work.

@jeremystretch commented on GitHub (Apr 18, 2017): > The first issue I run into is that I cannot have two racks named R1 in a single site even though they are in separate rack groups. This is covered by #238. Let's not duplicate the discussion here. > uniquity (word?) Uniqueness :smile: Currently, NetBox requires each device to have either a unique name, or no name. The proposal to shrink the scope of uniqueness to a rack group is problematic because racks don't need to be assigned to rack groups, and devices don't even need to be assigned to racks. This leads to very complex validation logic because (AFAIK) we can't just use the `unique_together` Meta attribute to enforce uniqueness across multiple tables at the database level. It would be feasible to make device names unique _per site_, but I'm not sure how useful that would be. The other problem is that, similar to #238, referencing a device by name now requires a tuple of (parent object name, device name). So importing interface connections, for example, would now require the user to first determine the site or rack in which every device exists. This is a substantial additional burden for users, especially those who employ only unique device names. As a workaround, could you name the PDUs following the pattern `R<rack>-PDU-[AB].<zone>.<site>`? I understand it's not the ideal solution, but it seems like it would work.
adam commented 2025-12-29 16:26:32 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Apr 18, 2017):

So I can, but, if I go that route, I might as well treat device and rack "names" as hostnames, which would easily be unique, but, requires redundantly storing the rack group and site slugs within and makes the UI real messy, especially on mobile devices.

Perhaps we could allow a mask on "name" such that it "hides" those redundant bits, this way the backend logic stays nice and simple and on the front end things look nice and clean.

This would also allow for ideal utilization in enhancements going forward where in the stored value:

device.name = R1-PDU-A.Z1.SITE1

could be used as:

device.named.masked = R1-PDU-A

...and one could then build:

{device.name.masked}.{rack_group_slug}.{site_slug}.DOMAIN.TLD

Would masking be possible as a compromise?

@bellwood commented on GitHub (Apr 18, 2017): So I can, but, if I go that route, I might as well treat device and rack "names" as hostnames, which would easily be unique, but, requires redundantly storing the rack group and site slugs within and makes the UI real messy, especially on mobile devices. Perhaps we could allow a mask on "name" such that it "hides" those redundant bits, this way the backend logic stays nice and simple and on the front end things look nice and clean. This would also allow for ideal utilization in enhancements going forward where in the stored value: device.name = R1-PDU-A.Z1.SITE1 could be used as: device.named.masked = R1-PDU-A ...and one could then build: {device.name.masked}.{rack_group_slug}.{site_slug}.DOMAIN.TLD Would masking be possible as a compromise?
adam commented 2025-12-29 16:26:33 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 18, 2017):

I'm opposed to building in any methods which intentionally omit data. A device's name should always be displayed in its full form within NetBox; any manipulation would need to be performed by an export template or external consumer.

@jeremystretch commented on GitHub (Apr 18, 2017): I'm opposed to building in any methods which intentionally omit data. A device's name should always be displayed in its full form within NetBox; any manipulation would need to be performed by an export template or external consumer.
adam commented 2025-12-29 16:26:33 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Apr 18, 2017):

OK, what if we had a user-definable column and the ability to hide a column (visible by default)

The user definable column could be built upon using available slugs/names/other bits and some basic regex capabilities?

Just spit balling

@bellwood commented on GitHub (Apr 18, 2017): OK, what if we had a user-definable column and the ability to hide a column (visible by default) The user definable column could be built upon using available slugs/names/other bits and some basic regex capabilities? Just spit balling
adam commented 2025-12-29 16:26:33 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Apr 19, 2017):

So in lieu of any added work on your end and before I dump, mass-modify and attempt to reload all my inventory, can you let me know if the Facility ID is a unique field as well for racks?

If that field is looser then I think I can make it work - thanks =)

@bellwood commented on GitHub (Apr 19, 2017): So in lieu of any added work on your end and before I dump, mass-modify and attempt to reload all my inventory, can you let me know if the Facility ID is a unique field as well for racks? If that field is looser then I think I can make it work - thanks =)
adam commented 2025-12-29 16:26:33 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Apr 19, 2017):

OK, reloaded all my data... This will work... Once version 2 drops I think we might need to look at making the tables responsive in a way that works better for mobile devices...

I don't mind taking a whack at that when the time comes and either making PR's or dropping screencaps on the discuss group

Feel free to close this if you have no other input, thanks @jeremystretch =)

@bellwood commented on GitHub (Apr 19, 2017): OK, reloaded all my data... This will work... Once version 2 drops I think we might need to look at making the tables responsive in a way that works better for mobile devices... I don't mind taking a whack at that when the time comes and either making PR's or dropping screencaps on the discuss group Feel free to close this if you have no other input, thanks @jeremystretch =)
adam commented 2025-12-29 16:26:33 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 19, 2017):

can you let me know if the Facility ID is a unique field as well for racks?

Just FYI, you can find this in dcim/models.py. The facility_id field is defined under class Rack as:

facility_id = NullableCharField(max_length=30, blank=True, null=True, verbose_name='Facility ID')

blank=True indicates that the field is not required. Although the field is not globally unique,

class Meta:
    ordering = ['site', 'name']
    unique_together = [
        ['site', 'name'],
        ['site', 'facility_id'],
    ]

indicates that, like the rack name, the facility ID must be unique per site.

@jeremystretch commented on GitHub (Apr 19, 2017): > can you let me know if the Facility ID is a unique field as well for racks? Just FYI, you can find this in dcim/models.py. The `facility_id` field is defined under `class Rack` as: facility_id = NullableCharField(max_length=30, blank=True, null=True, verbose_name='Facility ID') `blank=True` indicates that the field is not required. Although the field is not globally unique, class Meta: ordering = ['site', 'name'] unique_together = [ ['site', 'name'], ['site', 'facility_id'], ] indicates that, like the rack name, the facility ID must be unique per site.
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#871
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?