MKP Changes in 2.2 Discussion

Checkmk Exchange
1

Hello, dear community, especially – plugin developers.

Yesterday we had a community call where we talked about Beta 2.2 processes. One of the important changes is that Checkmk would be working differently with MKPs – and it is a breaking change that will affect many plugins.

We have decided that if there is enough interest, we could probably have a call with a developer to explain the changes to adapt the plugins to the new version.

What do you think?

11 Likes
2

yes, please.
And please also document all the necessary changes, so that everyone is able to implement these before the 2.2 release.

1 Like
3

First problem already here.

1 Like
4

All for it :slight_smile:

I suggest everyone who wants to join should just like the initial post unless we want to have 30 “yes please / all for it” replies :smiley:

2 Likes
5

Good idea!
I think we need enough interest from people, so that there’s enough people who’d join such session.

1 Like
6

Please schedule a call for this

7

I’m fine with such a session (of course), although I would feel much better if I knew what the main breaking changes are :grimacing:.
I know for sure that we have a poorly defined (virtually non-existing) API to the GUI world, which might lead to incompatibilities. Are there more problems that can be listed explicitly? If we have such a session we should make sure that the most qualified developer is present, and that might not be me :scream:.

Maybe in addition to liking the initial post we can collect some problems here (just bullet points, explicitly not addressing the problem in this thread)?

8

I was hoping to get this list from you (tribe29) :grin:

For now I have compiled a llist of potential pitfalls form the incompatible werks list:

  • Werk #13705: Special agents should not produce a check_mk section
  • Werk #13731: HW/SW Inventory: Remove ‘declare_invtable_view’ for registration of table views
  • Werk #14987: Extension packages: Enforce semantic versioning
  • Werk #14824: Custom extensions: Potentially incompatible change in GUI code
  • Werk #14821: Custom extensions might need adjustment due to refactorings in GUI code (Transform)
  • Werk #14719: Local customizations might need adjustment due refactorings in GUI code (PasswordFromStore)
  • Werk #14716: Local customizations might need adjustment due to structural refactorings in GUI code
  • Werk #14677: Remove item_name and item_help keywords from CheckParameterRulespecWithItem
  • Werk #14676: Item description in CheckParameterRuleSpecWithItem mandatory
  • Werk #14648: Pre 2.0 bakery plugins are no longer supported
  • Werk #14297: Remove pre-1.6 dashboard plugin compatibility
  • Werk #14084: Deprecate old HW/SW inventory plugin API
  • Werk #13887: Removed none_value keyword argument from Optional ValueSpec
2 Likes
9

I just comment here because I have written a few lines in the updated MKP articles and want to be informed on such a call to be able to improve the articles. In my opinion, such a session should focus on differences, glitches, pitfalls and improvements due to the new MKP management. API changes probably should not be the topic and be handled separately.

1 Like
10

thanks for the effort!

11
  • Documentation (e.g. how and which namespace to use for own extensions [hint in init.py:# namespace that can be shadowed/extended using the local/hierarchy.])
    • Reason: My dashlets (I just finished them for 2.0/2.1) are broken and I have no clue how and where to write them under 2.2 [copying the builtins directly in the /omd/versions directory does not yield new menu entries either]
12

Dear all,
The knowledge team and @mschlenker in particular created documentation on the incompatibility changes: Update to version 2.2.0

Can you please read the documentation article above and then vote on whether we need the call with clarifications?

  • Yes, there are still things that are unclear related to incompatibility of MKPs and I will join the call to clarify them
  • No, documentation is explaining the changes well enough. I will not be joining the call.

0 voters

13

@thl-cmk
As the new 2.2 stable is out today, I just wanted to follow up, which stumbling rocks are still in front of us?

Anything you may found in addition to your list posted in April we need to keep an eye on?

Kind regards

14
3 Likes
15

@foobar the work @_rb mentioned was the one I “stumbled” upon as well. Otherwise, I had no other points that were not in the listed works inside. But I haven’t ported too much to CMK2.2 yet…

16

Dear followers of the discussion,

Please take a look at the post with the werk above, that is marked as solution. This is the team’s advice on how to resolve some issues discussed, in the form of werk.

I hope this will be helpful to you,
Sara

17

Hello @Sara,

my issue (Dashboards/Dashlets) is still open.
They work in 2.0 and 2.1 but not in 2.2 and are not failing because of Werk #14297 (which was listed above).

The documentation how to write own Dashlets is stilll missing. The copy and modify approach did not work here. The problem here is, that it is not only the moved libraries, but a huge change in the structure how dashboards and dashlets are organized (init, register, link).

I know that this looks like a very special edge case, but I would be happy to talk to someone from Checkmk about that case. Perhaps at Checkmk Conference?

Kind regards
Stefan

18

Hello Stefan!

I will check with the colleagues who might know more about this and will let you know. The recommendations above are for many cases but, unfortunately, you are correct – they might not cover all the cases.

I will keep you updated on what I learn,
Sara

1 Like