As some of you know, we have been on the path to clearer, more transparent, more easily maintainable Developer APIs for some time now – at Checkmk we see the extensibility as a great product strength and want to continue on that path with the Check API v2.
To make sure that the transition is as painless as possible, we want to support you as much as we can with this.
As you know, we already did a livestream showing the migration of a plugin to the new version of the API. You can find it here: Plug-in Migration Livestream.
We also did a developer hour on the new APIs in March. Now we are glad to invite you to join the second and the last one on October 9th – where our developer lead Moritz Kiemer will answer any questions you might still have.
If you have a trickier question or would like to share some code snippets, please feel free to do so in the comments in this thread. Ad-hoc questions during the call will be of course also answered.
This plugin requires a password written to a local config file, so in _valuespec_myplugin I’m using the new Password object:
"password": DictElement(
parameter_form=Password(
title=Title("Password"),
help_text=Help("Password for access to the instance"),
custom_validate=(validators.LengthInRange(min_value=1),),
migrate=migrate_to_password,
),
required=True,
),
This stores then the password in my rules.mk file as:
so far so good, but… how can I then get the password in my bakery script (aka “bakelet”)?
Do I need to manually parse the tuple or is there already a prepared cmk function?
Thanks for the question! I will pass all of the questions here to the developer before the call so he could take a look and be able to answer as much as possible during the call
Well, not strictly check API related, but still.
How can I shadow a check that is written in the new API.
If I just try to use the same name as the original
Check, I get a “NameError” as it is already in use.
If I create a file with the same name as the original under ~/local/lib/python3/cmk/addons/plugins/checkname
the original file will not be shadowed.
The only way that seems to work at the moment is to put my file under ~/local/lib/python3/cmk/plugins/checkname. But then I have to reimplement everything from the original file, not just the parts I want to shadow :-(. And it’s not necessarily the path where user plugins should go, is it?
Cheers
Thomas
Ps: i hope there will be a recording as i am on vacation when the session is on
We are not planning to do a recording, as it is sometimes uncomfortable for the attendees but we hope to be able to create a blog post with Q&A based on the call.
@mimimi The “old” function wants a tuple (warn, crit).
The “new” function wants a tuple
('no_levels', None) # if the ruleset says "Do not impose any levels"
OR
('fixed', (warn, crit)) # this is the old behaviour
OR
('predictive', (...)) # for predictive checks. I don't know the exact format right now
If you use the SimpleLevels() element in the rulesets (aka WATO plugins), they will return one of the above.
@Dirk and @MasopustC are spot on. Since this is the main thing when migrating from v1 to v2, we will most likely cover this tomorrow. Additionally (or for everyone who can’t make it) you can see an example in this commit.
by using the part from your lookup_for_bakery. Pretty sure that this can be done better and/or more elegant, but…
Just one question: why did you use lookup for getting the secret and not extract ? What’s the difference?
Edit: seems it may be better to use extract here because it would even get a secret that is still in the “pending changes” state, isn’t it? And lookup would return the correct secret only after everything has been activated.
Hi Christian,
Regarding your code: type(bla) == blatype is considered bas practice. Better would be isinstance(bla, blatype); but these days I’d opt for
match pw:
case ("cmk_postprocessed", kind, ("explicit_password", (_id, actual_password))):
return actual_password
case ("cmk_postprocessed", kind, ("stored_password", (id_, _value))):
return lookup(..., id_)
case str() as actual_password:
return actual_password
case other:
raise TypeError(other)
This is called “pattern matching”, its worth reading into it :-).
As for the question which path to use: The general idea is, that without “activating”, changes in rulesets should not affect the monitoring. This principle is violated, if you use the pending configs path rather than the cores path, that’s why we went for the cores path. Having consistency for this question is the main reason why I introduced lookup_for_bakery. Whatever the decision is; if plugins disagree there will be chaos.
@moritz : you’ve probably seen that I’m not a python expert, so thanks for your detailed explanation! Also thanks for explaining why lookup should be prefered!
As always, at the end I’m learning something new here
