Adding Racks with the same name to different groups within same site

[LordBoBCUP]

Hi,

I am trying to add multiple racks and I was starting to name them via row#-rack# however, it seems that you cant have multiple Racks in the same site but different site groups with the same name. You can however if you are adding it to a different site altogether. Not sure if this is the intended workflow or not, or if I have to find a new naming scheme for racks in the same building just in different comms rooms or locations within the same site. E.G we have 2 different cages in 1 DC, I added each cage as a group, both in the same overall site. Do I have to configure each cage as an entire site? or should we be able to add racks with the same name to different groups within the same site.

[bellwood]

I'm not sure of your physical layout but if your cages are simply encompassing racks that are part of the row system then those racks should follow the same numbering scheme not reset within

If the cages are off to the side you might go:

cage#-row#-rack# where cage 0 is the common floor and increment cage for your actual cages

Reason being, lets say you tell someone to check out rack row01.rack01 and you have that assigned in a cage and on the common floor how do they know which rack to check?

[jeremystretch]

I think the impediment to allowing non-unique rack names within a site is that the rack group effectively becomes part of the rack name. So when importing devices, for instance, we'd need to specify the rack group along with the rack. I suppose it's a trade-off between flexibility in the data model and overhead.

[LordBoBCUP]

Yeah I see where you're coming from now. Basically in our of our facilities we have 2 cages that are at separate ends of the data hall because we purchased them at different times due to growth etc. Each cage's set of racks are numbered the same, i.e row then rack number in the row so I figured I could use the rack groups to signify the cages. I can see how this is going to get messy in once we add all of our facilities in, the devices and racks views are almost going to be redundant without filtering 100% of the time.

I guess in this case, for sanity's sake I'll have to duplicate the cage number/name as part of the rack name for all sites going forward, at least then I can still filter by name and get an order by location thats accurate without necessarily filtering for each query.

[jeremystretch]

@LordBoBCUP Out of curiosity, do you have unique facility IDs for your racks (e.g. identifiers assigned by the data center provider)?

[LordBoBCUP]

Hi Jeremy, yeah we do but the only place I've really seen them is on the invoices etc. Not really used in the real world. We could use them in netbox and have everyone reference them, but then again, each datacentre around the world would do them different as well, so uniformity would be lost. I guess if its not a feature thats super popular, people will find a workaround (probably the duplication/overhead)

[itmike]

How many levels of groups can you have in netbox?

eg. Site - DC - Server room - (Cage - )Row - Rack

[jeremystretch]

Site, rack group, rack, device. Each layer of organization adds a performance penalty.

#257 would add a region field to sites, but I think that's as far as we'll go.

[bellwood]

Just to add my .02 here as I'm running into similar issues where I'm working now.

We break the datacenters into zones and within those zones the racks and PDU's all have the same names.

So where I would have:

R1 in Zone 1 (Zone 1 is the rack group)
R1 in Zone 2 (Zone 2 is the rack group)

I cannot have two racks named R1, so I'm relegated to using:

R101 and R201, which isn't any help and has no "meaning"

My facility ID as well becomes complicated having to use a rack group:

R1.Z1 and R1.Z2

We maintain DNS for racks as such:

R#.Z#.SITE.DOMAIN.TLD

The same issue applies to devices, namely PDU's - we do:

R#-PDU-[A-Z].Z#.SITE.DOMAIN.TLD

However I can't have multiple R1.PDU-A (they exist in multiple zones / rack groups) so I need to do:

R1.PDU-A.Z1 and R1.PDU-A.Z2

It'll just make things a lot harder to with down the line when you'd want to just chain slugs or names together to have to potentially parse out redundant data (e.g storing the rack group in the name) and for future usage of Netbox features having to kitbash the names kinda suck being that we'd want to use:

Rack-Slug.RackGroup-Slug.Site-Slug.DOMAIN.TLD
DeviceName.RackGroup-Slug.Site-Slug.DOMAIN.TLD

My .02 being uniqueness for names should be scoped to the rack group level, please =)

Feel free to discuss on Freenode

[bellwood]

This has gotten worse.

I cannot have devices that are named the same between two different sites.

E.g I cannot have a "R6-PDU-A.Z1" in Site A and Site B

Just to clarify, both my sites are basically identical in naming convention, the only thing that is different is the site.

I have the same zone names, rack names and devices names, they simply have a different site ID in their hostname.

We REALLY need to relax this please.

[jeremystretch]

@bellwood Device naming constraints are unrelated to this issue. Please open a new issue if you'd like to discuss that.