Rack Group and Site Rack Capacity

[ryanmerolle]

Rack Capacity
Rack groups are often used to group racks within a site by room or some other grouping. It would be useful to associate a rack capacity to such a group. Similar to how you track a single's rack utilization by number of available rack units by subtracting space taken up by racked devices from the rack RU capacity, an optional field could be added to rack groups called something like "group rack capacity" where number of racks live could be tracked against deployed racks.

In the rack group and site list, it could then be displayed the total site and rack group utilization.

Integration with Floor Plans
If #114 was implemented, this could be implemented in a different way by reserving locations of the floor plan to set the limit of where Racks can be deployed based on dimensions.

Tracking Reserved Space
Similar to RU reservations, racks not yet installed could be reserved against the total capacity for a rack group or room.

[swerveshot]

I don't know if this was @ryanmerolle's intention (if not, this will be a nice addition), but it would be great if RU reservations have the ability to count towards a rack utilization. For instance in case you can't add any more devices because of maximum weight capacity of a rack. You could add a reservation for the remaining RUs and reach 100% administrative utilization in the rack overview.

[nzurku]

Have to agree with making rack reservations count against utilization. As a colocation provider, when someone rents a full rack, it makes more sense for us to make a 42 reservation than insert some sort of "42U fake device" since if we ever add a patch panel or a facility owned switch/device, we'd have to make a custom sized fake device to fill the rest.

I know for IP prefixes, there is a difference between setting something as a "Container" versus something else with how prefix utilization is handled. Perhaps racks should have a mode that can be put in that reservations count as utilization?

[tb-killa]

We wanted to ask again if this extension is planned in the near future ?
Currently we have to manually list or calculate the workloads due to major planning work.

[jeremystretch]

I'm cleaning up old issues, and this FR is just too broad to be actionable. I'm not necessarily opposed to any of these points, but a new FR is needed for each of them (if there's still demand) to discuss the exact implementations.