N°8515 - Add CMDB datamodel for Docker and Kubernetes #787

v-dumas · 2025-12-15T11:42:27Z

Base information

Question	Answer
Related to Combodo ticket?	N°8515
Type of change?	Enhancement

Objective (enhancement)

Document containerization in iTop CMDB as an installation option
It's mainly XML datamodel, with very little coded behavior

Checklist before requesting a review

I have performed a self-review of my code
I have tested all changes I made on an iTop instance
I have added a unit test, otherwise I have explained why I couldn't
Is the PR clear and detailed enough so anyone can understand digging in the code?

Checklist of things to do before PR is ready to merge

Set this module as an option below Virtualization
Get German/Spanish translation...
...
...

datamodels/2.x/itop-container-mgmt/dictionaries/fr.dict.itop-container-mgmt.php

Hipska · 2025-12-15T16:10:40Z

To me the link from ContainerImage towards ContainerApplication looks a bit weird. It feels it should be the other way around? Namely a container has 1 specific image and multiple containers can run the same image.

v-dumas · 2025-12-16T08:39:38Z

To me the link from ContainerImage towards ContainerApplication looks a bit weird. It feels it should be the other way around? Namely a container has 1 specific image and multiple containers can run the same image.

The name of 'ContainerApplication' is the most subject to discussion, at a point of time, I was about to name it Deployment.
It contains all the rules on how the various ContainerImages must be deployed on the container platform. It is truly a grouping of different Images, to combine them in an Application

Co-authored-by: Stephen Abello <stephen.abello@combodo.com>

Hipska · 2025-12-16T08:50:52Z

Wait, so what is the meaning of ContainerImage then? The image or the container that is running?

About the ContainerApplication, what kind of rules do you think of? It's not very clear to me what this object actually represents.

And does one of the objects represent that a container is actually running on one of the hosts/cluster? (I thought that would be what ContainerApplication meant)

v-dumas · 2025-12-16T10:15:53Z

We don't model in iTop what is actually running on any of the host.
We just document what is suppose to be running, but not how many containers of the same image are currently running on each host.
The ContainerImage is just an Image of a container, it's the reference of a piece of code.
That piece of code is expected to be running in one or multiple containers on the hosts/cluster, but again we don't say more than this piece of code is a piece of that ContainerApplication/Deployment which is running on that ContainerHost/Cluster

Hipska · 2025-12-16T11:26:50Z

Okay, I think I get it. But then again, why does the ContainerImage point to a ContainerApplication/Deployment and not vice versa?

An image could be used in/for multiple deployments. Where a deployment would indeed also have multiple images. Then, maybe it should be a N:N relation?

PS: ContainerDeployment would actually sound good 👍
PS2: Don't forget to add hash and (multiple) tags to ContainerImage. (What about a ContainerRegistry?)

datamodels/2.x/itop-container-mgmt/data/en_us.data.itop-container-type.xml

datamodels/2.x/itop-container-mgmt/module.itop-container-mgmt.php

v-dumas · 2025-12-16T12:05:25Z

Maybe it should be a N:N relation?
In a sense, it is already an N:N relation between ContainerApplication and Software

PS: ContainerDeployment would actually sound good 👍
Would it apply / make sense in all type of container platform?

PS2: Don't forget to add hash and (multiple) tags to ContainerImage. (What about a ContainerRegistry?)
You lost me completely, for me this object is just a reference to a software version used inside a containerized application.
What those 'hash' and 'tags' fields are used for? Is 'hash' related to the way the Image is encoded? And 'tags'

Any information related to the way a particular container image should be deployed on the Hosts/Cluster is not something I want to have in the model, because it is way to dependent on the technology. Maybe a file attribute 'Deployment recipe' on the ContainerApplication?

Hipska · 2025-12-16T13:41:01Z

You lost me completely, for me this object is just a reference to a software version used inside a containerized application.

So in this regards, a ContainerImage does not actually mean an image?

What those 'hash' and 'tags' fields are used for? Is 'hash' related to the way the Image is encoded? And 'tags'

See for example the tags for the iTop image we created at Super-Visions. What I named hash, DockerHub names digest, but it is actually a hash of the built image+version. Similar as what you have in git for a commit reference. So each build/hash/digest can have multiple tags (latest, 3.2.2, 3.2, ...). I was under the impression ContainerImage was a reference to this kind of images, but apparently I was wrong.

Any information related to the way a particular container image should be deployed on the Hosts/Cluster is not something I want to have in the model, because it is way to dependent on the technology. Maybe a file attribute 'Deployment recipe' on the ContainerApplication?

I Agree with that, only I don't know where you're referring to or to what you are replying to here?

jbostoen · 2025-12-16T16:14:17Z

Just a general thought: How is the decision taken what should be in iTop core vs. extensions?
I mean, I think the user base for the Azure datamodel is even greater than for Docker / containerization?

Besides that, happy to see this available!

v-dumas · 2025-12-19T14:24:05Z

See for example the tags for the iTop image we created at Super-Visions. What I named hash, DockerHub names digest, but it is actually a hash of the built image+version. Similar as what you have in git for a commit reference. So each build/hash/digest can have multiple tags (latest, 3.2.2, 3.2, ...). I was under the impression ContainerImage was a reference to this kind of images, but apparently I was wrong.

Well, for me a ContainerImage is a reference of this kind of images, there is no 'hash' nor 'digest' string, and maybe we should, but the url is supposed to be the full path to that image, something like "https://hub.docker.com/layers/supervisions/itop/2.7.13/images/sha256-754eb1f7b671a306432f92a14a80ddc4dac556e8809201e848df5e21305f6beb".

Hipska · 2025-12-19T14:48:55Z

Okay, thanks.

So my question I already asked a few times before is still relevant then:
Why does ContainerImage reference a ContainerApplication with the containerapplication_id field? Why can't a second deployment use the same image?

v-dumas · 2025-12-19T15:16:56Z

I suppose that you refer implicitly to Database normalization.
In this case, if we consider that the only information about a ContainerImage is it URL, the denormalization that I propose, will avoid one lnk table, make it easier for most people to update the URL of a ContainerImage just because they have modified the way to build their Application, with the drawback to have multiple ContainerImages pointing to the same URL, so duplicated information. But this duplication does not induce any risk of one being up-to date while the others are not, because the only pertinent information, the URL, is the logical unique identifier of a ContainerImage.
It's a perfectly arbitrary choice.

Hipska · 2025-12-19T15:33:20Z

I would urge to reconsider the choice made now that it is still possible. I foresee this to be more a pain in the ass when using this datamodel as a base for future extensions (Docker, Kubernetes, ... specifics) than what it currently solves (easier documenting deployments).

Hipska

This starts to look good 👍 Some comments..

Hipska · 2026-01-05T09:24:25Z

datamodels/2.x/itop-container-mgmt/module.itop-container-mgmt.php

+			if ($sPreviousVersion == '') { // First installation
+				$oDataLoader = new XMLDataLoader();
+				CMDBObject::SetTrackInfo("Initialization ContainerTypeInstaller");
+				$oMyChange = CMDBObject::GetCurrentChange();
+				$sFileName = dirname(__FILE__)."/data/en_us.data.itop-container-type.xml";
+				SetupLog::Info("Uploading Typology values for Containers from file: $sFileName");
+				$oDataLoader->StartSession($oMyChange);
+				$oDataLoader->LoadFile($sFileName, false, true);
+				$oDataLoader->EndSession();
+			}


Isn't this where data.struct should be used for?

There is a difference between what I have done and using data.struct. With data.struct, if you delete an entry it will come again on each iTop upgrade, with my solution it won't.

Hmm, thanks. Previously I had the impression that data.struct only gets processed on initial installation of the module..

Hipska · 2026-01-05T09:25:40Z

datamodels/2.x/itop-container-mgmt/datamodel.itop-container-mgmt.xml

+        <field id="publisher" xsi:type="AttributeString">
+          <sql>publisher</sql>
+          <default_value/>
+          <is_null_allowed>false</is_null_allowed>
+        </field>


This should probably be an AttributeExternalKey?

I have mirrored the Software object design, because a Container Image is a kind of Software, and in general you don't want to mix up your customer and organizations like PHP or Ngnix

Hipska · 2026-01-05T09:56:27Z

datamodels/2.x/itop-container-mgmt/data/en_us.data.itop-container-type.xml

+  <ContainerImageType alias="ContainerImageType" id="1">
+    <name>Docker Hardened Image</name>
+  </ContainerImageType>
+  <ContainerImageType alias="ContainerImageType" id="2">
+    <name>Docker Official Image</name>
+  </ContainerImageType>
+  <ContainerImageType alias="ContainerImageType" id="3">
+    <name>Verified Publisher</name>
+  </ContainerImageType>


Will this work? I think this needs its own file, if not just for better overview.

Yes, it does work.

N°8515 - Add CMDB datamodel for Docker and Kubernetes

079c384

CombodoApplicationsAccount added the internal Work made by Combodo label Dec 15, 2025

steffunky reviewed Dec 15, 2025

View reviewed changes

datamodels/2.x/itop-container-mgmt/dictionaries/fr.dict.itop-container-mgmt.php Outdated Show resolved Hide resolved

datamodels/2.x/itop-container-mgmt/dictionaries/fr.dict.itop-container-mgmt.php Outdated Show resolved Hide resolved

v-dumas and others added 2 commits December 16, 2025 09:40

Capital letter with an accent

99e7463

Co-authored-by: Stephen Abello <stephen.abello@combodo.com>

Capital letter with an accent

180fc1a

Co-authored-by: Stephen Abello <stephen.abello@combodo.com>

Hipska reviewed Dec 16, 2025

View reviewed changes

datamodels/2.x/itop-container-mgmt/data/en_us.data.itop-container-type.xml Show resolved Hide resolved

datamodels/2.x/itop-container-mgmt/module.itop-container-mgmt.php Show resolved Hide resolved

v-dumas added 5 commits December 23, 2025 12:44

N°8515 - Add lnkContainerApplicationToImage and more fields on Image

e283f01

N°8515 - Move ContainerApplication under SoftwareInstance

856a63b

N°8515 - Finalize Cloud, add Setup sub-option

1a7f8b1

N°8515 - Class description fine tuning

12f7171

N°8515 - Class description fine tuning

91ad9be

Hipska reviewed Jan 5, 2026

View reviewed changes

N°8515 - Add CMDB datamodel for Docker and Kubernetes #787

Are you sure you want to change the base?

N°8515 - Add CMDB datamodel for Docker and Kubernetes #787

Uh oh!

Conversation

v-dumas commented Dec 15, 2025

Base information

Objective (enhancement)

Checklist before requesting a review

Checklist of things to do before PR is ready to merge

Uh oh!

Uh oh!

Uh oh!

Hipska commented Dec 15, 2025

Uh oh!

v-dumas commented Dec 16, 2025

Uh oh!

Hipska commented Dec 16, 2025

Uh oh!

v-dumas commented Dec 16, 2025

Uh oh!

Hipska commented Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

v-dumas commented Dec 16, 2025

Uh oh!

Hipska commented Dec 16, 2025

Uh oh!

jbostoen commented Dec 16, 2025

Uh oh!

v-dumas commented Dec 19, 2025

Uh oh!

Hipska commented Dec 19, 2025

Uh oh!

v-dumas commented Dec 19, 2025

Uh oh!

Hipska commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Hipska left a comment

Choose a reason for hiding this comment

Uh oh!

Hipska Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

v-dumas Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

Hipska Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

Hipska Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

v-dumas Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

Hipska Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

v-dumas Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Hipska commented Dec 16, 2025 •

edited

Loading

Hipska commented Dec 19, 2025 •

edited

Loading

Hipska Jan 5, 2026 •

edited

Loading