Community Call: DevHour on Developer APIs

Hello Community! :wave:

There are questions about the new DevAPIs – and we want to support you in creating new Checkmk extensions and migrating the old ones to the maintained version.

If you have questions about developing Checkmk extensions, our next Developer Hour is a great opportunity to ask them. @Rebekka will be there to share her expertise with you.

If your question is on the trickier side or is long and requires some reading beforehand, please add it to the document in advance with your name or username – that way we can prepare. Live questions during the session are also welcome, of course – but we cannot guarantee that we can answer them straight away.

Join us in Zoom on Tuesday, 4th of November, at 3 PM Berlin time.

Looking forward to seeing you!

6 Likes

Regarding what we discussed with deprecated inventory views.

We will soften the texts a bit. But basically anything in a directory below local/share/check_mk/web/plugins/… is regarded problematic by us, because we (and also your users) will not know, if the plugin will work in a future version. The logic is at the moment quite simple - if there is something in this directory, we start annoying you.

The good piece: you can acknowledge the user messages now.

The better piece: from 2.5.0, there is the Inventory UI API. We (or rather Simon) is confident that this will be stable in 2.5.0. But we are looking for feedback - so please give it a try and let us know if this works for you or not. Once it is stable and released, we can not make changes to it anymore.

3 Likes

@martin.hirschvogel Is there any chance we can get a recording or transcript of the session? I’m assuming that the topics and content would be very valuable for the community as a whole who are looking to upgrade or port to the new API.

2 Likes

Hi Mark!

We do not record these community calls for two reasons:

  1. (the important one) we want everyone to feel comfortable to share and express themselves, which sometimes might be tricky with recordings, as not everyone is comfortable with being recorded and then having the video with them uploaded online.

  2. this is a Q&A format, so basically answering the questions of people who attend the call – some of the answers might be useful for others but some cover specific situations. If a community call has a part where we present something, we share the presentation file of course, or any other related files.

Good news is – we have had quite a few DevHour sessions like this one and there is a good chance that there will be another one coming :slight_smile:

3 Likes

Hi all,

I have now finally some updates about the questions from the last call.

Regarding the overshadowing of shipped checks and rulesets, especially legacy ones:
As mentioned in the call, shipped plugins can be overridden by placing the modified plugins under ~/local/lib/python3/cmk/plugins instead of ~/local/lib/python3/cmk_addons/plugins.
API v2 check plugins take precedence over legacy checks and with #werk 18965 API v1 rulesets now also take precedence over legacy rulesets. The {family} folder is not important for the replacement of legacy plugins, only the name needs to match.

Regarding shipping additional python packages:
For bakery plugins this is not supported.
For normal plugins you can place the python package under ~/local/lib/python3, e.g. ~/local/lib/python3/paho. You can then package paho in your MKP and import from it as usual in your plugin.

Regarding the custom_validate field for MonitoredHost/MonitoredService:
Thanks to the question we noticed that the custom validation was not being triggered for a number of FormSpecs.
You can see the affected FormSpecs in #werk 18966.
Unfortunately this means invalid configurations may be present if you used the custom validation for any of the mentioned FormSpecs. Those will have to be fixed manually by the user when the validation now takes affect.

6 Likes

Hello Martin, hello Rebekka,

can you provide an example for the new Inventory UI API?

I can’t find one in the sources or in the online doc.

Greetings
Stefan

1 Like

I added a simple example to the devel_inventory_plugins article a few days ago. It is neither translated to English yet, nor picked to 2.5.0:

2 Likes

Thanks Martin,

the force was with me and I figured out where to place the Node()-definitions. I have seen the file you mentioned, but didn’t get the idea how it will be loaded.

Then “~/local/lib/python3/cmk_addons/plugins/{family}/inventory_ui/columns.py” was a good guess from me and I now can extend and define own column names for our inventories.

Side note:
In server_side_calls-API-doc it is explicitly written where to place the file and the Quick Guide is what I’m missing in the other plugin docs:

~/lib/python3.13/site-packages/cmk/server_side_calls/init.py: * The file with the plug-in has to be placed in the server_side_calls folder

In plugin API doc:

(Advanced) Example (for the docs, please use it if you want it):

#!/usr/bin/env python3

# The file with the plug-in has to be placed in the `inventory_ui` folder (e.g. "~/local/lib/python3/cmk_addons/plugins/{family}/inventory_ui/columns.py")

import re
import time

from cmk.inventory_ui.v1_unstable import (
    Label,
    Node,
    NumberField,
    SINotation,
    Table,
    TextField,
    Title,
    Unit,
    View,
)

UNIT_BYTES = Unit(SINotation("B"))

def _render_date(value: int | float) -> Label | str:
    return str(time.strftime("%Y-%m-%d", time.localtime(value)))

def _sort_key_version(value: str) -> tuple[int | str, ...]:
    parts: list[int | str] = []
    for value_part in value.split("."):
        for part in re.split(r"(\d+)", value_part):
            try:
                parts.append(int(part))
            except ValueError:
                parts.append(part)
    return tuple(parts)

node_software_packages = Node(
    name="software_packages",
    path=["software", "packages"],
    title=Title("Software packages"),
    table=Table(
        view=View(name="invswpac", title=Title("Software packages")),
        columns={
            "name": TextField(Title("Name")),
            "arch": TextField(Title("Architecture")),
            "package_type": TextField(Title("Type")),
            "summary": TextField(Title("Description")),
            # sort_key enables from-to filtering
            "version": TextField(Title("Version"), sort_key=_sort_key_version),
            "vendor": TextField(Title("Vendor/Publisher")),
            # sort_key enables from-to filtering
            "package_version": TextField(Title("Package version"), sort_key=_sort_key_version),
            "install_date": NumberField(Title("Install date"), render=_render_date),
            "size": NumberField(Title("Size"), render=UNIT_BYTES),
            "path": TextField(Title("Path")),
            "language": TextField(Title("Language")),
            "product_name": TextField(Title("Product")),
            "classification": TextField(Title("Classification")),
            "approval_state": TextField(Title("Approval state")),
            "release_date": TextField(Title("Release date")),
            "provided_by": TextField(Title("Provided by")),
            "product_name": TextField(Title("Product name")),
        },
    ),
)

Greetings
Stefan

Already looks great and helpful! Pathes are mentioned and the concept is well explained. The advanced functions (colors/sorting) will only be explained in the plugin API doc?

1 Like

For now, I want to keep the documentation of the unstable APIs to the bare essentials. They might change, so my primary goal is to provide working minimal examples and everything else should be looked up in the reference.

Second, there is other stuff in need for documentation. The next devel topic, I’ll do will probably be rulespecs, formspecs and migrations. We currently only have the basics, no nested examples. Then bakery API v2_unstable.

So, I’ll most likely change the devel_inventory_plugins to more UI stuff for Checkmk 3.0 when the API moves to stable.

6 Likes