Bakery plugins, rulesets

Checkmk Dev&Exchange
,
1

As part of my org’s effort to migrate our custom plugins to a 2.4 compatible state, I need to update the bakery plugins and rulesets for the packages. I see both in practice and in the documentation that both the bakery plugins and rulesets use the old style .register type API. When packaging, I get notified of a deprecated file still present in the package due to either the API used in the bakery files, their location, or both.

So, should I be using the “new”/“v1” ruleset API for bakery plugin rulesets now? If so, what location does it need to live in to be valid?

1 Like
2

Update: I got my hands on a complete .mkp compliant with the “new” API standards (shoutout to “Veeam for Office 365 Checks” by jiuka). It looks like the bakery plugin is still valid using the old “.register” style API and location, but the ruleset updated to the new API and location. I’ll update my ruleset accordingly and post the results.

3

A few weeks ago, I was wondering the same. I just switched the ruleset config to “new style” and simply extended the rulset config:

"""

File: ~/local/lib/python3/cmk_addons/plugins/adp/rulesets/ruleset_adp.py

Check Configuration Options (WATO)
"""

from cmk.rulesets.v1 import Label, Title
from cmk.rulesets.v1.form_specs import TimeMagnitude, TimeSpan, String, List, BooleanChoice, DefaultValue, DictElement, Dictionary, Float, LevelDirection, SimpleLevels, SingleChoice, SingleChoiceElement
from cmk.rulesets.v1.rule_specs import Help, AgentConfig, CheckParameters, HostCondition, Topic


def _parameter_agent_config_form():
    return Dictionary(
        elements = {
            "deploy_plugin": DictElement(
                parameter_form=BooleanChoice(
                    label=Label("Deploy plugin to server")
                ),
                required=True,
            ),
        }
    )

def _parameter_plugin_config_form():
    return Dictionary(
     ...
   )

rule_spec_plugin_config_adp = CheckParameters(
    name = "adp",
    title = Title("ADP status"),
    topic = Topic.GENERAL,
    parameter_form = _parameter_plugin_config_form,
    condition = HostCondition(),
)

rule_spec_agent_config_adp = AgentConfig(
    name = "adp",
    title = Title("ADP status"),
    topic = Topic.GENERAL,
    parameter_form = _parameter_agent_config_form,
)

This simple approach works for me…

My actual bakery config lies in ~/local/lib/python3/cmk/base/cee/plugins/bakery/adp.py and uses:


register.bakery_plugin(
    name="adp",
    files_function=get_adp_files,
)

-Daniel

4

Thanks for the input of your way, Daniel. That does seem like it would work, but to keep consistency with how the rest of our plugins are written the ruleset for the bakery plugin is in its own file for now. Maybe future me will get around to optimizing the structure of our plugins after the legacy → check v2/ruleset v1 migration is finished.

As it stands, using the current, v1 ruleset API and file location to create a ruleset for the bakery plugin works correctly and registers as compliant. On that note, any reason why the bakery is still using a legacy style API? And do you know if that’ll break any time soon?

5

No, I have no idea why the old API style is still used for the bakery, but I assume it’s only a matter of time before the developers address it. Since there’s no deprecation warning, I believe we’re safe until at least version 2.5.

1 Like
6

Yes, this is an inconsistency we are currently discussing within the product management team. Since the scope of the bakery API is not as wide as with check APIs, impact and thus priority are currently rather low.

I have just updated the article on how to use the bakery API and picked it to 2.3.0. This also points on some minor things to care like casting timeranges from float (new ruleset APIs) to integer (old bakery API).

2 Likes