N°8515 - Add CMDB datamodel for Docker and Kubernetes

[v-dumas]

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...
• ...
• ...

[Hipska]

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]

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

[Hipska]

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]

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]

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?)

[v-dumas]

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]

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]

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]

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]

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]

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]

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]

Please add a newline at the end of each file.

[v-dumas]

I did it but what is the purpose ?

[Hipska]

You added 2 extra newlines 😛 that has indeed no use.

A single eol is best practice and doesn’t mess things up when handling files in commandline or programmatically.

[Hipska]

Consistent description, same for all other occurrences.

Suggested change

	// Class Container Image
	// Class: ContainerImage

[v-dumas]

Why do you want this ?

[Hipska]

Consistency with all other occurrences. I thought this was the guideline.

[v-dumas]

comment