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.
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.
@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.
We do not record these community calls for two reasons:
(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.
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
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 FormSpecsin #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.
