Support for nested rack groups

[jeremystretch]

Issue type

[x] Feature request
[ ] Bug report
[ ] Documentation

Environment

• Python version: 3.5.2
• NetBox version: 2.2.6

Description

Currently, a rack must be assigned to a site and may optionally be assigned to a rack group. Each rack group must be assigned to a site. This allows e.g. to represent cages within a site. However, this model is limited to a single level of grouping. It would be beneficial to support nested rack groups (similar to regions) so that we could model subgroups of racks within a cage, for example. Additional research is needed to determine how feasible this is.

[jasonguy]

@jeremystretch I thought the Tenancy aspect, from the Data Center viewpoint, was equivalent to the "cage". Perhaps I misunderstood the purpose of the Tenancy feature, (which is typically a term used for VRFs or VLANs) but the description says "Customers or departments", which seems to me like the cage in the DC. Then within the cage, you have Racks and optionally Rack Groups.

[jeremystretch]

@jasonguy The concept of tenancy covers many objects in NetBox (sites, racks, VRFs, circuits, etc.). It might make sense to assign a tenant for a specific device, or a whole rack, or a whole cage, depending on your use case.

[jeremystretch]

@Maxkaha Please keep comments pertinent to the issue. If you have other questions or suggestions, please open a separate issue if it seems appropriate to do so after consulting the contributing policy.

[jeremystretch]

It will be interesting to see if we can implement both this and #238.

[puck]

How about carving up racks for multi-tenancy within a rack? This can become a bit more interesting with #554 . I'd like to be able to say that a customer can manage the space they've been allocated within the rack, and that's it.

[ryanmerolle]

With this feature, you may want to enable support for more details about a rack group. IE for tracking cages, a colocation provider (or the users of the netbox deployment) may have specific details tied to a cage like descriptions, tenant(s), tenant group(s), tags, or status. You could also argue that rack groups should track available power, rack space (may not be a good name, but track how many racks in that group could be provisioned), and other "datatypes" not currently found in netbox.

This could be a separate feature request, but I think its pertinent to the overall vision of nested rack groups for depicting cages. Let me know and I can split this out if needed.

[DanSheps]

@jeremystretch Along the same vein as this, would it be possible to look at sites being recursive in addition?

The reason I ask, is I can see a site being more akin to:

• Building
• Building Area
• Room

And Rack groups being more in line with groupings within a room, ex:

• Cage
• Rack Row
• Rack "group"

If it makes sense, I can open an enhancement issue for it as well so that it can be tracked.

This would allow the ability to do things like have vlans/vlan groups assigned to a master site, and then have rooms under that site which could have a single vlan assigned to that room.

That said, I could see this causing a lot of checking needing to be done all over as it would potentially touch a large number of areas. For instance, in the vlan example, you would need to not only populate the immediate site vlans but also the parent vlans for a device in a room.

[jeremystretch]

I've been digging into this a bit and updating an existing model to sublcass MPTTModel is a bit tricky. This introduces four new database fields (lft, rght, level, and tree_id) which must be initialized for all existing objects (i.e. any RackGroups which have already been defined). This is normally achieved by calling e.g. RackGroup.objects.rebuild().

While the fields can be added via a migration without issue, we don't have access to MPTT's TreeManager within the migration, so we can't call rebuild(). The method's logic is pretty simple though, so we could emulate it with regular update() queries, however this results in an exception when the migration is run: django.db.utils.OperationalError: cannot CREATE INDEX "dcim_rackgroup" because it has pending trigger events. We would need to split the rebuild process into its own migration to avoid this (and we'd still have to hack together our own clone of rebuild()).

Another option is to leverage the post_migrate trigger to automatically call RackGroup.objects.rebuild() when the migration completes. This seems like a cleaner solution, though we probably don't want to force a rebuild of the tree for every migration. Unfortunately it doesn't appear possible to limit this to certain models.

[jeremystretch]

I ended up separating the operations into two migrations and mimicking rebuild(), which seems to be straightforward enough.