Hello,

Following this Idea, this requirement https://docs.centreon.com/docs/installation/prerequisites/ about browser would be to follow the Extended Support Release versions depending browser editor strategy (Mozilla, Microsoft, Google, Apple)

https://www.mozilla.org/en-US/firefox/all/#product-android-release

https://learn.microsoft.com/en-us/deployedge/microsoft-edge-support-lifecycle

https://chromeenterprise.google/browser/

Regards,

Greg

@gespada : I don’t know for the other browsers but Firefox ESR is only supported a little more than one year. So I don’t get your point. The idea is to have a version of Centreon supported more than two years, at least four imo.

https://support.mozilla.org/en-US/kb/firefox-esr-release-cycle

Hello @Stéphane 

By my comment it’s not a idea to reduce the period of the LTS who you mentioned. I agree with all you write on your post.

LTS could be a great idea to have a more robust Centreon app, with many old bug who could be fixed.

As you indicate, LTS will provide a large application of bugfix, security fix and limit or maybe don’t introduce breaking change who arrive logically with the next major release.

By that, i think it’s could be more easy to maintain the UI, or others features of Centreon app i imagine, also

Yes, we could see this mode (ESR) is more used by Mozilla, Google/Apple have a Cloud approach, with a word update! Microsoft have extended stable channel, who is not reprensentative of an ESR version of Firefox.

But, using an ESR version of client, is a way to follow the requirements during the LTS period, by a reduction of compatibility with a dedicated version for enterprises (Centreon sell Centreon Business Edition)

Also for large organization/enterprise who have a long process to update client side (Computers), with some legacy apps or others things who could block the update of version, ESR version of client is a good approach.

Build a web application who is compatible with many version of browser is a challenge, some tools exists to test many browser like selenium server or others, but you provide all the time effort for that.

By exemple, actually, between a 19.10 and a 22.10 UI has really different with i imagine many evolution of framework, libs, third party libs and others components who could introduce incompatibility at client side. And cause many bugs by that.

From my opinion, “maybe i’m wrong”. i don’t think it’s possible to have a LTS, because some change introduce to Centreon and so Breaking Change, who cause many qualification and requalification of the new version before installation, are due to Centreon Cloud from a side, who generate many of new features. From other side a little the customer. By exemple because he don’t want elaborate a process by exemple to maintain the centreon-plugins (who introduce sometimes Breaking Changes) and generate work about the Host Template, Service Template and Command Custom, with a specific approach, not using plugins pack definition, no usage of discovery module by exemple.

Regards,

-------------------------------------------------------------------------------------------------------------------------------------

Bonjour @Stéphane 

Par mon commentaire, il n’est pas question de réduire la période de support LTS que vous mentionnez. Je suis en phase avec ce qui est écrit.

Une LTS serait une excellente idée pour avoir une application plus robuste, avec bon nombre de vieux bugs qui pourrait être corrigés.

Comme vous l’indiquez, LTS fournirait un grand nombre d’application de correctif, correctif de sécurité et limiterait ou bien n’introduirait pratiquement pas de rupture de compatibilité, qui arriverait logiquement avec les prochaines versions majeures.

Par ca, je pense qu’il serait plus simple de maintenir l’interface utilisateur, ou d’autres fonctionnalités de l’application Centreon j’imagine aussi.

Oui on peut voir que ce mode (ESR) est plus utilisé par Mozilla, Google/Apple ont une approche plus cloud, avec un mot d’ordre mise à jour! Microsoft dispose lui des canaux stable étendus, ce qui n’est pas représentatif d’une version ESR de Firefox.

En utilisant les versions ESR des clients, c’est un moyen de suivre les pré-requis tout au long de la période LTS, en réduisant la compatibilité sur des versions qui sont dédiés aux entreprises (Centreon commercialise la version Business Edition)

Aussi pour les grandes organisations/entreprises qui ont un long processus de mise à jour côté client (PC), avec beaucoup d’ancienne applications, ou autres qui bloque les montées de version, les versions ESR sont une bonne approche.

Concevoir, une application web qui est compatible avec beaucoup de version de navigateur est un challenge, il est vrai que certains outils de test existe comme les serveurs Selenium et autres, mais on fournit tout le temps beaucoup d’effort pour ça.

Par exemple, actuellement, entre la version 19.10 et la 22.10, l’interface utilisateur est vraiment différente, avec j’imagine beaucoup d’évolution du framework, des librairies, des librairies tierces et autres composants, qui peuvent introduire des incompatibilités côté clients. Et cela apporte son lot de bugs

De mon point de vue, “je me trompe peut être”, je ne pense pas qu’il soit possible d’avoir une LTS, parce que certains changements introduits dans Centreon et donc des ruptures de compatibilité qui nous provoque beaucoup de qualification et re qualification de nouvelle version avant leur installation sont dus à Centreon Cloud d’un côté, qui génère beaucoup de nouvelle fonctionnalités. De l’autre côté un peu du client. Par exemple parce que ce dernier ne veut pas élaborer de processus pour maintenir à jour les centreon-plugins (Qui introduise quelques fois des ruptures de compatibilité) et génère un charge de travail à mettre à jour des modèles d’hôtes, modèles de service et commandes personnalisées, avec une approche spécifique, pas d’utilisation des plugins packs et pas d’utilisation du module de découverte par exemple

Cordialement,

@gespada :

”By exemple, actually, between a 19.10 and a 22.10 UI has really different with i imagine many evolution of framework, libs, third party libs and others components who could introduce incompatibility at client side. And cause many bugs by that.”

I use multiple browsers with Centreon (mostly the last Firefox, Firefox ESR), and many of my users use Chrome or even an obsolete Firefox version. For the last years, I don’t remember of a client-side bug, all the bugs I noticed and reported were server-side. So I’m not sure a LTS version would many impacts (maybe none) on this point.

About your second argument : having a separate centreon-plugins repository would be a good thing whatever we’d have a LTS or not. For the plugin packs, there is already a repository for each Centreon version, so you’re already supporting multiple versions for packs. So what I told about Centreon applies the exact same way to the plugin packs: you’ll be finally supporting less versions in a given time.

No needs to have a LTS for Centreon cloud (which is basically a SaaS solution for Centreon if I’m not mistaken?), so the users don’t even bother with updates in the first place with a SaaS solution, do they?. Maybe I didn’t get your point but I see absolutely no relation between the LTS subject and Centreon cloud. Yes, many new features were requirement for Centreon cloud, the fact is, with a LTS version, those features wouldn’t have be introduced in the current LTS before the next LTS. So all the bug introduced with those new feature wouldn’t have impacted on-premise LTS users. And yes, it would have been a great time saving for us.

Breaking things for on-premise, existing users, to propose a SaaS solution, is definitively not acceptable in anyway, imho.

Was SaaS a request from existing Centreon client or something Centreon thought it would be a good thing to be able to propose new market share? Maybe both, then still, I wonder.


 

We are looking at having a specific repository for plugins as you mentioned.

However as far as LTS is concerned this is a difficult topic because of 3rd party code on which Centreon has dependency which would not be maintained over the course of a long period (e.g. 5 years) thus causing incompatibilities and unfixed vulnerabilities. Let us discuss internally and see how we could both offer a longer term support and reduce the number of supported versions at any moment.

About this : I noticed Centreon relays on the “Remi” repository, at least for PHP. Is it a common practice to use this repository for PHP? What’s the level of trust one can have in packages coming from this repository, compared to, for example, PHP packages provided by RedHat?

“Remi” repository is a 3rd party repo that we used previously to get PHP supported version on EL7 (CentOS 7).

Recently we chose to move to PHP 8.1, but because it was not present in default OS editor repository, we explained in our documentation how to install Remi repo.

Maybe it was not a good chose to move up PHP version to fast and we should wait new PHP version on OS editor repo.

We will keep PHP 8.1 for next major version because this one will be available on EL9 (and I hope it will be available in standard with Software collection for EL8).

Yes Remi repo is not an Operating System Editors repo but Remi is the maintener of PHP packages on Enterprise Linux (EL).

Regards,

Obviously I’m not the only user who would like a LTS release of Centreon and I exposed you how it would lead to fewer different version to maintain, and all other advantage it has, but you decline the proposition. That’s your choice anyway.

All I expect is that all the breaking changes and regressions, or obvious bugs which should have never passed quality tests,  will be less often encountered in the future releases.

With frequent changes in the technology landscape, an LTS is not something we want to proceed with. 

That being said, your point is valid and we have to offer stability when users upgrade to a newer version.

Just moved this idea back to In Backlog. In the past year, we’ve continued discussing with users and thinking of how our version lifecycle could evolve to best address all types of needs. After several iterations, we have agreed to a potential solution. Happy to discuss it if you drop me a private message.

We are going to get LTS for next release. Please read 

« Tout vient à point à qui sait attendre. » ^^

This is a good thing having a LTS release. Thanks for this.

 Delivered in 24.10. See 

Hi,

This sounds like good news.

I’m not sure what means: “Centreon Open Source versions will be  supported for 18 months.”

Does it mean the LTS life cycle does not apply to the Centreon’s core components, but only for the proprietary ones? What does it mean?

Also about “The Centreon Cloud environment adopts a continuous delivery policy and its software version is always up to date.”

Does that mean different customers of the SaaS product may have different versions? If there is a common “rolling release” version of Centreon (that would be the SaaS “up-to-date” version), why on-premise customers couldn’t use it, or at least test it, if they will?

I see the demo (demo.centreon.com) still shows, for a while, version 23.10.5. Does it means the SaaS “up-to-date” version currently is a 23.10.5? If yes, why is it so?

 

“Centreon Open Source versions will be  supported for 18 months.” means that only customers with active support will benefit from updates post 18 months (i.e. updates for core components will be available from private repositories that will only be accessible to actively supported customers -a communication will be sent to notify that change-).

Centreon Cloud instances are all using the same version that is fully validated in the Centreon Cloud environment. On-premise environments have a list of possible setups (OS, database, HA/non-HA, remote servers etc) that prevents us from being able to continuously test and release new features. That being said we are continuously delivering minor updates (“patches”) and are evaluating doing proper on-premise beta versions in the April timeframe.

Please don’t look at the demo. This system is not a Centreon Cloud instance and will be retired. Also Cloud instances have different version numbering than on-premise with release notes updated separately when a new version is pushed.

“updates for core components will be available from private repositories that will only be accessible to actively supported customers”

This is sad.

Moreover, I can’t see how this complies with the GPL licence. If modifications on the GPL licenced parts of the code are done, they must be accessible to anyone asking the source code, hence not not only available to a private, reserved to paying users, depository.

Sorry I looked at the demo…

“Cloud instances have different version numbering than on-premise with release notes updated separately when a new version is pushed”

So it is assumed that cloud instances aren’t, forcibly, running any GPL licenced Centreon

code?

Maybe it’s time to release Centreon under a BSD licence then. Would be less messy…

Don’t get me wrong, the source code will still be available and updated, I am talking about packages that will be in a private repo after 18 months.

OK