FeatureWishlist

Feature Wishlist

This is a random list of desired features.

• Clone an object
  • Some attributes would be copied (SW version, RAM) but some would not (serial number, MAC addresses)
• Re-discover an object
  • NICs may be exchanged in a server, or a blade may be added to a switch. Re-discovering the object would add/change ports and other attributes, but wouldn't delete any existing data unless confirmed by the user.
• Trace the cable path
  • There are cases where a device is connected to a patch panel, which is then connected to another patch panel. This chain could continue for several hops until reaching the final destination device. Display the 'final destination' port and object on the port listing. Also provide a 'traceroute' link which displays all path details in a pop-up window.
• Allow duplicate IPv4 networks, at least for the private space.
  • When assigning a non-unique IP to an object, ask the user to specify which subnet it is from.
• Provide an 'Integrity Check' report which lists problems
  • Tables using the MyISAM engine which should be using InnoDB
  • Missing system-level rows (Attributes, for example)
  • Missing foreign keys or triggers
  • Invalid data which cannot be constrained using foreign keys
    • EntityLink table
      • Verify that referenced rows exist
      • Validate parent/child relationships (parent_id != child_id, a child cannot be its own grandparent)
    • Config settings such as IPV4OBJ_LISTSRC (an object type may be removed from the list, even if objects of that type exist and have IP addresses assigned)
• Manage plugins from the web interface
  • Install/uninstall, enable/disable capability capability
  • Install/uninstall features handle DB table creation/destruction
• Dictionary:
  • Move object Make/Model information out of the Dictionary
  • Additional information needs to be stored. Using dedicated fields is a cleaner approach than the current one (stapling it on, separated by GPASS or other % wrappers)
    • Suggested fields:
      • Make
      • Model
      • Category (replace chapter_id, sample types are server, network switch, etc.)
      • Type (rack-mountable object, module, component)
      • Height, depth (only applies to rack-mountable objects)
      • Rows, Columns, Orientation (only applies to chassis objects)
      • Template (described below)

---

• Suggest stratification of dictionary entities to permit entries with as much information a possible.
  • Instead of a dictionary entry for (chosen randomly) "SuperMicro 4U 7048R-C1R4+". Create dictionary entries for:
    • "SuperMicro"
    • "SuperMicro 4U"
    • "SuperMicro 4U 7xxx"
    • "SuperMicro 4U 7048"
    • "SuperMicro 4U 7048R"
    • "SuperMicro 4U 7048R-C1R4+"
  • This permits entering as much possible information as is available. When I get a "SuperMicro 4U 7048S" device, I can still enter it as "SuperMicro 4U 7048" providing as much info as possible.

---

• Object templates
  • The current SNMP discovery functionality covers two core areas - interfaces and attributes. If an object is modular, the number and type of interfaces may vary. Some objects are static, such as non-stackable switches. Using a template for static devices would ease the process of adding them, especially in cases where there is no SNMP support in RackTables.
  • There are also cases where SNMP-derived information isn't necessary. A user may want to add the object in order to document the rackspace allocation and port connections. Documenting port MAC addresses and other attributes such as serial numbers and SW version provides limited or no value. Using a pre-defined template, ports could be added during the object creation process. If desired, SNMP re-discovery could add the missing information at a later date.
• Refactor user management
  • The first time a user logs in via an external authentication source (LDAP), a record should be auto-added to the UserAccount table.
  • Today, user accounts cannot be deleted. Users should never be deleted from the DB because various tables record their actions. Add a 'deleted' column to the UserAccount table and provide a way to 'delete' them from the web interface (the 'deleted' column would be set to true').
  • The user_name column must be unique, but only for 'undeleted' accounts. Use DB triggers (ideal) or PHP code to ensure uniqueness.
  • Change existing tables to reference UserAccount by user_id instead of user_name (IPv(4|6)Log, MountOperation, ObjectHistory, ObjectLog, PortLog, TagStorage, UserConfig, VLANSwitchTemplate).