As we prepare for the stable 2.4 release, we’d like to once again highlight the new DevAPIs introduced in version 2.3, which will make earlier plug-in versions incompatible with 2.4.
To support you in migrating your plug-ins to the new and more maintainable DevAPIs, we’re hosting a series of Developer Hours in the coming months. These sessions will give you the opportunity to speak directly with the people best equipped to help: our Checkmk developers.
We’ll kick things off with our first meeting, which will begin with a live demo. Our developer Rebekka will migrate a plug-in from the Exchange in real time to demonstrate the process. This demo will be livestreamed and recorded for our YouTube channel.
In the second part of the session, we’ll have a Q&A. The recording will be turned off for this segment to ensure a relaxed atmosphere where everyone can comfortably ask their questions and join an open discussion.
We’re looking forward to seeing you on 23 April at 3pm (Berlin time) on Zoom!
To help us prepare the most comprehensive answers and shape the meeting around your needs, please consider submitting your questions in advance using this document.
Shoutout to Brian, so he can hopefully reshare me the vs-code addonlist + the json on pastebin
For now, I’ll look for equivalents, based on Rebecca’s pycharm addons.
The WSL one is just because I run a WSL2 container on my work Windows laptop to ease accessing my Linux resources. It’s not needed for development as far as I know.
Here’s the <OMD_ROOT>/.vscode_server/launch.json
Again, this is what I came up with to get the VSC debug tool to run. It’s not official, and I don’t promise it will work for you.
Then you’ll need the remote ssh connection set up to your site. Set up as <siteuser>@<cmkserver> with ssh key auth. I left my connection at the site user home directory.
From my experience it is not needed at all. All my rule files are working without extra init files.
It is not necessary to work but better for troubleshooting and testing.
If you look inside the extensions in the Checkmk github then all are using the type declaration.
But this was existing since some versions i think. (in 2.1 i saw the first migrate functions)
And i ignored it all the time
This was also existing before. But it was not so clear in the older versions.
_(“String”) meant there this string can be replaced with translation strings.
I only added the __init__ files in this specific case due to the edition specific bakery ruleset (in the cee folder). Usually you can ignore them.
The README in the treasures folder clarifies that scripts in there are not officially supported by Checkmk and most of the migration helpers also have some disclaimer at the top. This is also why we will stop shipping them with Checkmk altogether.
But it is true that this is not obvious in the documentation itself.
We wanted to draw attention to them since they have helped us during our migrations and hopefully will also save other plugin developers time, but they are by no means perfect.
Previously this functionality was its own Valuespec called “Migrate” that provided a wrapper for the Valuespecs to be migrated.
With the API introduction this is now more relevant due to the underlying data models changing for some Valuespec to FormSpec migrations. For some common migrations there are already predefined functions available via cmk.rulesets.v1.form_specs.migrate_*
There was also a question regarding migrating colors to the new API from I believe @fabian.binder. We don’t have a stand-alone script to do this, but using the functionality from the migration helper, especially _parse_legacy_metric_info, you need can use something like
def migrate_color(legacy_color: str) -> None:
if legacy_color.startswith("#"):
rgb = _rgb_from_hexstr(legacy_color)
else:
rgb = _rgb_from_legacy_wheel(legacy_color)
migrated_color = min(
(_Distance.from_rgb(rgb, color) for color in metrics.Color),
key=lambda d: d.distance,
).color
print(migrated_color)
