Question 1

How is CI data stored physically?

Accepted Answer

Table-per-hierarchy: every CI row lives in the base cmdb_ci table plus its class-specific extension tables. sys_class_name identifies the concrete class.

Question 2

What is sys_class_name?

Accepted Answer

A column on every extended table that stores the concrete class of the row, so a base-table query can return polymorphic results with the right subclass attributes.

Question 3

Difference between cmdb_ci_appl and cmdb_ci_business_app?

Accepted Answer

cmdb_ci_appl is a runnable software instance (e.g. Tomcat process). cmdb_ci_business_app is the business-level app (e.g. 'Payroll') that consumers know by name.

Question 4

When should you create a new CI class?

Accepted Answer

When a class of CI has distinct attributes AND distinct identification rules. If it only has extra fields, extend an existing class instead.

Question 5

You need to model Kubernetes clusters, nodes, and pods. Where in the tree?

Accepted Answer

Use OOB Container CI classes (cmdb_ci_kubernetes_cluster, cmdb_ci_kubernetes_node, cmdb_ci_kubernetes_pod) if the plugin is enabled — they ship with identification rules. Only extend cmdb_ci_appl if you truly have a new class of thing (rare); otherwise use OOB and add u_ columns. Alternate: Alternate: for exotic platforms, extend cmdb_ci_cloud_object rather than inventing a new root class — you inherit cloud discovery hooks. Pitfall: Inventing new root classes fragments identification and Service Mapping traversal.

CI Classes & Tables — hierarchy and inheritance

Definitive questions

Scenario drills

Choosing where to add a container platform

Approach

Alternate approach

Pitfall

Grow this section