search

Icinga / helm-charts

Kubernetes Helm charts to deploy a ready-to-use Icinga monitoring stack.
https://icinga.com
Apache License 2.0
8 stars 11 forks source link

[Bug]: Chart metadata is incomplete #47

Open thekoma opened 3 months ago

thekoma commented 3 months ago

Affected Chart

icinga-stack

Which version of the app contains the bug?

No response

Please describe your problem

Hi! The icinga-stack Chart.yaml must contain the dependencies metadata, which does not.

martialblog commented 3 months ago

Hi, thanks for the hint. Go ahead if you want to open a PR to fix it.

thekoma commented 3 months ago

Hi @martialblog is a little more complex than a simple PR as it involve publishing the various packages instead of using direct submodules. Which makes sense as if you want to build the stack as a stack AKA every component could be installed by itself. To do so we would need to move/copy the submodules in the chart folder and release all of them first. Using a same level structure for your charts: New structure

Then we need to update the dependency of the icinga-stack Chart.yaml expliciting the dependency on the repo itself: Chart.yaml

The Workflow also needs to be updated slightly (but has to be done after moving around the directories): The lint test wasn't testing all the charts as a chart but only the first module with the submodules, this is not a good idea as you wouldn't be able to check the singles modules for faults. Linting Workflow

The release workflow if you remove the path (which by default is $root/charts) will iterate on every chart and release every one of them for you. Release Workflow

After that I would suggest to also add an OCI release and a signature to keep the enterprise grade quality of the project.

If you want I can gladly land an hand but I would like to discuss how to move the things around before pushing.

Uh, also the gh-pages branch needs cleanup.

thekoma commented 3 months ago

Just to be safe, is it ok for you if I create a PR with all the changes? Because seems a lot for a "non official contributor" to change the architecture in that way. And time is valuable for everyone so I'd rather not spend your investing mine.

lippserd commented 3 months ago

Hi @thekoma,

I've only briefly looked at the structure you suggested, but it sounds appealing that you can install Icinga 2, Icinga Web, Icinga DB, Icinga for Kubernetes each on their own or install the entire Icinga stack.

Since I don't really know much about Helm 😆, why do have we to release individual components first if we have a dependency on our own repo? Wouldn't that also mean that we have to release our charts in a certain order afterwards? I would also change the structure a bit so that you can install everything related to monitoring Kubernetes without having to install Icinga 2, Icinga DB and the other things like Director etc that would come from the Icinga stack:

@mocdaniel If I'm not mistaken, that's something on our roadmap anyway, isn't it?

Best regards, Eric

thekoma commented 3 months ago

As far as I've seen in your structure each componenti can be installed separately and receive the information of the other components in the form of services or secrets.

In that way substantially the dependency is not strong or even present.

The idea of dependency topically comes from a tight bound of two components or as a commodity.

For example you can build an app that requires redis to work and you can add a dependency as: Strong: The chart won't work without the redis chart

Modular: The chart has a boolean flag declaring the dependency that will provide a set of default values, or in case of false accept the information of where to find the resources provided from the needed dependency (address of redis name of db username password etc)

In your case everything seems modular enough for the single components but not enough for the stack.

So in the stack I would have put a strong dependency on the underlining modules and no dependency on the modules themself.

Anyway releasing the stack as is right now will throw errors in various linters as the charts under it are not versioned in the metadata of the stack itself.

As said before I would like to take half an hour discussing the "plan" to land an hand in a way that makes the most of everyone times.

thekoma commented 3 months ago

Uh almost forgot:

why do have we to release individual components first if we have a dependency on our own repo?

Each chart could be used separately (for example the db part could be used as a central component while the api part can be used in frontend nodes/clusters.

Wouldn't that also mean that we have to release our charts in a certain order afterwards? You will need to create the dependency first and then the other components the first time only. As releasing the stack with the subparts as dependency would fail (duh). But after that you would be able to declare the dependency and the release in a much more resilient way.

For example using the typical semver v1.0.0 you can set the boundaries for the stack to accept for the version v1.0.x of your stack helm any chart ~v1.0.* of the subcharts. At the same time releasing the v1.1.0 of the chart for, let's say icinga-Kubernetes would be automatically excluded from who has 1.0 stack installed thus providing a more conservative/stable deploy.

As an additional added value the helm charts have a double versioning. One for the chart itself and one for the app providing. In that way you will be able to provide a simple matrix knowing that the chart >=1.1.* will include the version of the app X.Y.Z that is compatible only from that version up.