CMDB - bschmalhofer/otobo-ideas GitHub Wiki

CMDB

CMDB stands for configuration management database, that is a database of configuration items. But there is no exact definition. See https://www.nm.ifi.lmu.de/~brennera/files/CMDB_Patterns_BDIM.pdf.

Current Implementation in OTOBO

General Catalog

A controlled vocabulary. See https://github.com/RotherOSS/GeneralCatalog/. The relevant tables are general_catalog and general_catalog_preferences. general_catalog contains a list of names for a class. Each name has key value pairs attached to it. Relevant classes are:

  • 'ITSM::ConfigItem::Class'
  • 'ITSM::ConfigItem::Computer::Type'
  • 'ITSM::ConfigItem::DeploymentState'
  • 'ITSM::ConfigItem::Hardware::Type'

An example from the default setup after installation of ITSM. The class ITSM::ConfigItem::Class contains the name Hardware. The class ITSM::ConfigItem::Hardware::Type contains hardware types like Beamer and Camera. The latter class is in the config item class 23:

- Key: Type Name: Type Searchable: 1 Input: Type: GeneralCatalog Class: ITSM::ConfigItem::Hardware::Type Translation: 1

ITSM Core

See https://github.com/RotherOSS/ITSMCore. Table cip_allocate is apparently not relevant for the CMBD.

ITSM Configuration Management

See https://github.com/RotherOSS/ITSMConfigurationManagement. Table configitem , configitem_definition ,configitem_version, configitem_counter, configitem_history_type, configitem_history

Dependencies between configuration items

Linking is done with the OTOBO core tables link_type, link_state, link_object, link_relation.

Additionally there are object specific event handlers that are called during linking.

In OTRS 7 there are CI References. Are the same tables used there?

Requirements for making the CMDB pluggable

  • Config items classed must be extractable from the source
  • Config item definitions must be extractable
  • List of possible values must be extractable
  • Linking
    • Ticket
  • Searching
    • Per default when linking to a ticket: Name, ID, Type
    • Can Agents search for a computer with a specific CPU ?
  • Statistics
    • Maybe specific SELECTs for statistics
  • History
    • Kept as a list of change actions in configitem_history ?

Other implementations of CMDBs

i-doit

BMC Helix CMDB

iTop

Ralph

CMDBBuild

SnipeIt

DATAGERRY

ServiceNow

versio.io

Others

  • there are many others
  • didn't find any with the tree data approach used by OTRS

Standards

Frameworks for data aggregation

Nobody cares how the data is stored internally. Everybody wants and easy way of getting the inventory in.

ITSM by Freicon

  • monitos inventory
  • LANSweeper

Talend

  • Data integration platform.
  • has an open source version
  • many connectors

Pentaho

  • Open Source

Requirements for Data Storage

This is mostly inspired by from section 5.5 of https://www.dmtf.org/sites/default/files/standards/documents/DSP0252_1.0.1_0.pdf.

  • a wild, not necessarily connected, tree of items linked by directed relationships
  • a relationship is an extension of an item, source and target are added
  • items have an ID
  • items have a name, possible aliases
  • items have a history
  • items have records
  • records can be nested, JSON like
  • items have a type, which defined which records are possible
  • types can be extended
  • relationships can be restricted to linking specific types
  • searches by records must be efficient

Ideas for the Data Storage

See also Nested Annotations

Dynamic creation of database tables

  • This seams to be the mainstream, likely for a good reason
  • linking should be efficient
  • adding "further properties" as JSON is possible

JSON in relational DBs

XML in relational DBs

  • Oracle seems to have full support for XQuery
  • MariaDB, PostgreSQL seem to only support XPath 1.0
  • using XML looks like a bad idea

a synthesis: generate DDL from JSON Schema

more Ideas

Semantic Data Graph

Rich CI relations

Ability to select all members of a list without resorting to 'LIKE'

Dynamic fields as values for config item records

loader classes for syncing

DBIx::Class

  • in case dynamic tables are wanted

REST Interface

Sprinkle in some OpenAPI

GIS

RDF

Going semantic would break with tradition.

Use an existing framework for data aggregation