Hi,
I just learnt there are breaking changes in the last Centreon plugin packs release. As versions 22.10.X of Centreon also relies on those plugin packs, it results in breaking changes introduced in Centreon 22.10.
Plugin packs now have the same naming than the other Centreon parts (YY.MM.XX), having packages labelled *23.04* in a repository with an URL like */22.10/* is odd, to say the least.
I think the previous versions of any Centreon package still are available in the repository, I haven’t checked but I hope it’s true for plugin packs also.
What would be the cost, the technical difficulties, to have a per major version plugin packs repository to avoid breaking changes for a non major upgrade? Is the recent change in the naming a first step to such a resolution of the issue?
Breaking changes and packs/plugins
+13Hi
Your post raises two questions: about versioning and about breaking changes.
About the versioning
The versioning of the Monitoring Connectors (formerly Plugin Packs) has always been independent of Centreon releases.
The last connectors release is 23.08 and contains packs that can be installed and used with any version of Centreon, even old versions such as 2.8.
We have been using the YY.MM convention since april 2022 to make it homogenous between connectors, since we release them every month. Previously some were versioned 2.0.8 whereas some were 5.1.3 although modified at the same time, which made even less sense.
About breaking changes
What we announce as breaking changes is enhancements or refactoring that may cause some configured services to need reconfiguration to continue functioning as before. Installing a pack would never break Centreon.
We try to avoid it as much as we can and we advice users to read the release notes before upgrading the packs. We will try to improve the information given regarding breaking changes in the future.
I hope I managed to clarify what breaking changes are in the perpective of Monitoring Connectors, and how they are versioned.
Hi,
Thank you for all those details.
>Installing a pack would never break Centreon
IMO it does not have to result in a plain fail of the application itself to be qualified as a breaking change, requiring mandatory configuration changes from the user suffices to be qualified as such.
Actually it forces us to take a lot of precautions for any upgrade (downtimes, step by step upgrade and close watching of what happens at every step). We have to take care of the behaviour and possible failure of every application interfaced with Centreon (our job scheduler for example). Also, when dealing with automated (or semi-automated) support ticket creation, a relatively little batch of false alerts may have painful consequences.
But what we need is to see the existing bugs/problems we have being fixed/resolved. And moreover, no new bugs introduced!
It has passed only sixteen days between 22.10.11 and 22.10.12. I made the upgrade of our Centreon production platform from 22.10.7 to 22.10.11 ten days ago (it went smoothly this time, thx to the developers for that!), but I did the upgrade of monitoring connectors and plugins two days ago only, in a separated operation. It went also relatively well, but only because I watched closely our critical set of monitored resources, and so was able to manually set a downtime when a curious change in the centreon-plugin-Operatingsystems-Windows-Snmp (or is it in PHP?…) lead to some false alerts on numerous resources. I was then able to avoid the creation of more than a dozen entries in our ticket system and thus all the time consuming administrative work and financial consequences it’d have implied for us.
If your able to access it, you’ll find all the details in the #66505 ticket I opened at the Centreon commercial support for this issue. It is currently partially fixed (by a configuration change but some questions remain), hence the ticket opened at the support). I think you can understand why I just can’t serenely upgrade to 22.10.12 in the next days, our users would, legitimately, protest if the least new annoyance of that kind would happen again, in a such short period of time.
I’d say I have basically two wishes for the future of Centreon, which you are free, of course, to consider or not:
1) More bug fix, even if it necessarily means less new features
2) Smoother upgrade process and more backward compatibility
Last thing, a remark, maybe you’ll prove me wrong, but still nowadays, all software editors who adopted a XX.YY.ZZ version numbering did it following the major.minor.revision concept, where a revision increment must strictly be limited to security or anyhow critical fixes, but should never introduce new feature or even more obviously, require any configuration change from the user. Whatever major and minor are released at fixed date or not. While this is definitively not an obligation of any kind, it is a tacit convention for decades.
Thx for reading so far. Have a nice day.
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.