Current model: hierachy

• object (not mounted)
  • port
  • port
  • port
  • IP address
  • IP address
  • IP address
• object (not mounted)
• object (not mounted)
• Rackspace
  • rack row
    • rack
    • rack
    • rack
  • rack row
    • rack
    • rack
    • rack
  • rack row
    • rack
    • rack
    • rack
      • object
      • object
      • object

A rack is always a part of a rack row (sometimes referred to as "rack frame"). Objects may be mounted to one or more racks. Ports always belong to an object and may be connected to any other ports. IP addresses are discrete points of an object's relation to IPv4 space, which is measured by its own dimensions.

Current model: design flaws

• There are no additional layers like rooms, floors, buildings and so on, where they could be necessary.
• Objects cannot reside in a rack without allocated rackspace (which sometimes just happen). Hardware cannot be just stacked in a room (although in real world it sometimes is).
• An object cannot be further refined into a chassis with modules: disks, line cards, system boards, power source units and so on.
• Same is true for software components, namely, virtual machines.
• It's not possible to have a rack alone --- a dummy rack row is necessary.

Future model: design

There should be physical and logical entities of several types:

• location
• rack
• object
• module
• virtual machine

Some of above could act as containers for others:

• A location can contain another locations, racks, objects and modules.
• A rack can contain objects.
• An object can contain modules and VMs.

Entities may be contained in abstract manner, in this case they should be arbitrary sortable within containing entity. Entities may be contained in structured manner, in this case it is done through a "map" of the container. A good example of a map is the current implementation of racks.

Objects and modules may have hardwired ports attached to them. An important difference is that module cannot operate by itself, it must be plugged into an object first. This means, that when a module isn't plugged, the user will not be able to install a link to its ports. Likewise, "unplugging" module should trigger breaking of all port links installed on it (or be blocked).

A map is a two-dimensional discrete space consisting of cells. For the sake of simplicity, all maps are rectangular. Each map can be referred by more, than one container. Map cells may represent:

• air -- here be dragons
• ground -- chassis or floor
• water -- module slot, rackspace unit or mounting base

Each "water" cell belongs to a slot. Each slot must have at least one cell assigned to it. Each slot can only have one entity "plugged" into it, but the same entity can occupy more, than one slots on the same map. E.g. there are double-sized line cards and rack objects usually take more, than one rackspace atom (often even more, than one unit).

There should be some mean to control, which particular modules fit into particular objects, but it's not clear at the moment.

Future model: implementation

There are two major processes here: to develop means, that would allow users create new structures, and to convert existing databases into the new format.

Software components to rework/develop

• Asset viewer.
• Viewers of all rack rows, racks and objects.
• Map editor.
• Port selector.

(to be continued)

Upgrades

• All rack rows must be converted into locations.
• All racks must be made to use maps instead of rackspace atoms.
• All network switches, which are known to be modular ones, should have respective maps attached. IOW, these maps must exist.

(to be continued)