On Fri, Mar 4, 2011 at 11:10 AM, Les Mikesell <lesmikesell@xxxxxxxxx> wrote: > On 3/4/2011 8:24 AM, Tyler J. Wagner wrote: > >> On Fri, 2011-03-04 at 07:56 -0600, Les Mikesell wrote: >> >>> But the hard part (and much of the point of racktables) is the visual >>> display. >>> Can you generalize how nested objects should appear? Or should only >>> racks be >>> displayed with the containing objects just used for navigation?. Or only >>> the >>> innermost objects - or objects that have rack position and size >>> attributes? >>> >> >> I would again define that by ObjectType. For ObjectType "Rack", define >> it as having a number of rows with 3 columns (front/middle/back). For >> ObjectType "Row", define it as having an number of columns with 1 row >> each. For ObjectType "Room", define both rows and columns as >> configurable. Leave the x and y as definable on each object, with some >> sane defaults defined in the ObjectType template. >> >> Allowing more columns would also solve the tall PDU problem. Racks could >> have columns for the PDUs with one row in them. >> > > If you are conceptually nesting things, shouldn't columns inside a rack > become arbitrary slices within the outer space? Most of mine don't quite > fit a front/middle/back layout even though it comes close. > > In this case, visualisation must either be a flat x by y grid (like >> now), or we'd have to actually define things in 3D and have multiple >> views. Flat is good enough for now, even if it makes the tall PDU column >> look odd. >> > > What do you do if you have a pair of tower boxes sitting on a rack shelf > side by side? > > -- > Les Mikesell > lesmikesell@xxxxxxxxx > > > You have the same problem if you have a rack full of mac mini servers. I can fit them flat 2 wide and 3 deep in a rack (6 servers per U). Or I can stand them on end and 30 per 5U (10 across, 3 deep) -matt