Hi,
we recently updated our central site and our ~40 satellites of our customers from 2.1.0p45 to 2.2.0p38
In order to be able to go to the newest version 2.3.0 we need to make all our self written checks ready for that. In 2.3.0 the new Check API version 2 is used for that.
However in 2.2.0 I think only the API version 1 is available. Is that correct?
So, what I want to prevent is doing that migration work more than once.
Ideally I would like to change all our checks, so that they will work in 2.3.0 and 2.4.0, so I don’t have to touch them anymore for a long time.
Since the API v2 is not available in 2.2.0, I won’t be able to test the new checks directly in our production environment and use a test instance instead.
The other path would be to make everything run with API v1 in 2.2.0, which will probably still work in 2.3.0 (right?) and then do it again for API v2. I’ve no experience with these new APIs, so I don’t know how much additional effort this would be. Making the checks already work in 2.2.0 would definitely make our lives easier during the days after the upgrade.
What do you suggest?
Is there a freelancer out there who did something like that already? I don’t know how much budget we have for something like that, but I’m sure we can figure something out.
fron 2.2 to 2.3 there are no changes in the agent-based plug-ins (as were none from 2.0 to 2.1 to 2.2).
The only area, where changes were are the GUI extensions (e.g. rulesets, metrics/graphs), which had no standardized API until 2.3
From discussions which I had the changes in 2.2 to 2.3 for the GUI extensions are not so drastic (also knowing that the devs tried to make that step acceptable). To enable people to go quickly on 2.3 and then adapt their plug-ins to the new GUI APIs. Also the agent-based API v1 is still there in 2.3
If you come from 2.1 and have the checks written already in the 2.0 style → checks inside ~/local/lib/check_mk/base/plugins/agent_based/
Then you have nearly no migration issues with 2.3 - you only need to migrate from this to the new API style before 2.4 upgrade.
But if your own checks are mostly inside ~/local/share/check_mk/checks/ then you need to do a little bit more migration. If you don’t want to break anything at update time it would be.
Old 1.6 checks migrated to 2.0 style, make upgrade and then after 2.3 upgrade, migrate these to new API.
Such a huge step 2.1 - 2.2 - 2.3 with many own checks is not possible without testing instance and sample hosts from production environment for check migration.
regarding upgrade errors, has anybody encountered the next error in a distributed setup ?
The central (Version: 2.3.0p12, Edition: CEE, License state: licensed) and remote site (Version: 2.2.0p27, Edition: CEE, License state: unknown) are not compatible. Reason: Target version too old (older major version is not supported).
We have upgraded ALL systems at the same time, in the overview window the remote sites reported it was running 2.3.0p12 but the master detected an older version ?
And more funny was : the other 2 sites reported correctly and are working …