Hello Icinga community,
I noticed that the SUSE corner of the Icinga repository is not up to date anymore, no Icinga 2.13.3 or Icinga Web 2.10.x
Is this just an error/oversight or should we switch to the openSUSE repo?
Well this is quite unfortunate. Also it’s a bit irritating that there is now information given how and why the SLES packages are “revamped”, especially since openSUSE and SLES achieved binary compatibility. While I understand the changes for RHEL because of the changes with CentOS Stream this doesn’t seem like a logical/sensible step.
1 Like
This is not only “unfortunate”.
Don’t get me wrong, but I think this is an outright horrible decision. I’ve been promoting Icinga with my customers for years now as being a true open source solution, and now I find myself in the position to tell them that their CentOS-based monitoring infrastructure will not get any upgrades anymore for the time being, and potentially never again.
And this affects not only CentOS 8 (which indeed has been discontinuned, another unfortunate development in the open source world), but - as they are binary compatible and rely on the same RPMs - AlmaLinux 8 and Rocky Linux 8 as well.
Could it be that this decision has been made because customers might come to the conclusion that they don’t want to pay for Icinga on RHEL 8, but use the CentOS/Alma etc. packages for free instead?
Guys, I really feel betrayed by Icinga at this point. If I have to explain to my customers that they will not receive any further updates for their RHEL systems without buying a subscription, and possibly no updates for CentOS, 7 or 8, Stream or not, at all, I can as well pack my things and go home.
I’ve been promoting Icinga since 2016. I would really like not to be proven wrong. It’s your business decision without doubt, but as far as I’m concerned if this is the last world mine is pretty clear as well. And given the fact that I invested a lot of time and effort into Icinga I would really, really regret that.
4 Likes
We are also not amused about the possibility for Icinga to go “open core”, as implied by the CLA and the subscriber only repo, the focus on diversity and inclusion instead of professionalism, the new ugly theme with so many problems with modules, removal of the classic and solarized dark themes and the handling of our issue on this topic (https://github.com/Icinga/icingaweb2/issues/4729).
As we use the solarized dark theme on our dashboards on the walls, we now have to maintain it on our own and provide it to the community (https://exchange.icinga.com/slalomsk8er/Solarized%20Theme).
In the end, we still decided to buy a support contract as we required more assistance and wanted to have higher priority for our issues but the above mentioned issues definitely rubbed me and my team leader the wrong way!
2 Likes
I usually leave this up to my colleagues responsible for these decisions, but I feel the need to address some of your concerns myself now as I’m fully behind said decisions.
– @pete
Let’s start with the sentiment that open source software and related installments like packages must be freely available without any cost. Open source software itself is indeed free in terms of access, but this doesn’t include free distribution. You personally are free to distribute Icinga software, but you may require payment in exchange. Packages are a service and a separate piece of software if you will.
So this decision regarding the distributions Icinga provides packages for, has nothing to do with being true open source or not. It has rather something to do with, you guessed it correct, business. I’m an employee of Icinga, my colleagues are as well. We have also trainees, regularly. All get paid.
We can add features, fix bugs, address questions on the forums and write hopefully useful blogposts. 
And we can live from it, go on vacation, raise kids, etc.
And that’s not because Icinga is open source.
Let’s move on what happens with CentOS Stream, Rocky/Alma Linux and what this has to do with RHEL and SLES. That there are no packages for CentOS Stream is not Icinga’s fault, it’s a new distribution and the successor of CentOS. From my understanding, but bear with me please I’m not a sys-admin, this isn’t just an upgrade from one version to another. In Icinga’s view, Stream, Rocky and Alma Linux are competing alternatives. Icinga can’t and (probably) won’t provide packages for all them and hence still gathers data which distribution gets the most traction in the community. This is still an ongoing task.
Icinga never had packages for Rocky and Alma Linux, so the only really unfortunate development was that Redhat decided to change direction with their CentOS distribution. There are no packages for Stream, not because it’s technically difficult, but because Icinga expects users of CentOS to be equally offended by this decision. So the chance that Rocky or Alma Linux get the broader traction is possible. This isn’t a new development at Icinga, we have always weighed which distribution we provide packages for based on requests by the community, support customers or internal requirements. CentOS Stream is just another entry on this list, now.
Then there’s RHEL and specifically SLES. Icinga had packages for both in the past. For RHEL not so much, because these were technically the CentOS packages, but for SLES definitely. But as I explained at the beginning, this was a business decision. Users of RHEL/SLES are mostly companies themselves and pay for support on these platforms, so it’s not dubios of Icinga to also require payment for it’s services (packages). It’s not been welcomed much though, as expected. But there’s no other reason.
– @rivad
Now onto that “open core”, whatever this is. Please explain this to me, I really don’t know it. But I know the contributor license agreement (CLA), because I know my contract with Icinga. There is a similar statement included. You should read up on the term before alleging Icinga a degradation of professionalism.
Ugliness and beauty is, god bless, in the eye of the beholder.
Which many problems with modules are you talking about? Regarding the theme changes of course. There was only a single fix in the Director, which got delayed.
What has been bad at my (yes, that’s me) handling in your issue? I told you why we removed the solarized-dark theme and that you can personally continue maintaining it. I see absolutely no problem here. If you are offended by the fact that we removed the theme, okay. But as with all parts of our software, we’d have to maintain it if we continue including it. It’s been a community contribution from the very beginning. Now, given the fact that so much changed in terms of theming, we didn’t see a reason to keep it because our dark theme is so similar. If anyone really needs the same greenish (ugly, in my opinion 
) styling the theme can again be maintained externally, like you did now. That’s what open source software is for.
Thanks for the detailed answer in this thread also, besides the other mentioned one above. I think we wrote a lot of statements, sights etc. there
Such a side note: maybe it would be an idea to merge these threads to discuss in one and not in many threads with the same topic?
What I can tell you about Stream. After the deciscion from RHEL about CentOS Linux and CentOS Stream: There was a “small” migration update which switched CentOS Linux 8 to Stream. It was called “centos-release-stream”. Described e.g. here: https://www.cyberciti.biz/howto/upgrade-migrate-from-centos-8-to-centos-stream-conversion/
What I’ve read until now that Rocky/Alma Linux is now what CentOS Linux usally was: I clone of RHEL.
As I understand it, CentOS Stream is testing for RHEL you can use it for development and testing of the packages for the next REHL releases. Rocky and Alma Linux are clones of REHL in there “raison d’être”. So you shouldn’t care, if the packages work on Rocky or Alama, as long as they work on RHEL and if the packages aren’t working, it’s by definition a bug in the distribution.
“open core” is the monetization model, of for example GitLab, where you have a community edition and a enterprise edition. In short you have to pay for some feature like for example to get rid of the ugly warning in the search on GitLab CE and to get the full power of the search function.
The concept of open-core software has proven to be controversial, as many developers do not consider the business model to be true open-source software. Despite this, open-core models are used by many open-source software companies.[4]
To prepare to switch to open core a CLA is needed as without it one can’t easily dual licence the code.
The part about the professionalism has nothing to do with the license but with the energy that the company invests into virtue signaling of values of one political leaning. The older I get, the more my politics lean the other direction or the left is leaning more and more and my views stay more or less in the middle. Anyway, before I start rambling about politics, I would just like to see the companies I support to keep out of this game and focus there energy into the product.
No, beauty isn’t in the eye of the beholder, there are rules and some universals, also one can just ask around to find out. I did and nobody on my team and the others I asked, like the new theme. This is a illness that also plagues my workplace as our new document templates have bad readability and the color combinations are just garish - a lot worse then the new theme.
As for the “bad” handling of the issue, I’m just not happy with the decisions to remove the old themes as we use them and prefer them to the new ones. As you say, there is some taste and opinion about colors so why not have a selection? I encourage you to have a look at https://ethanschoonover.com/solarized/ and discover how much work went into this and why it’s one of the most popular themes - at least popular enough for a community contribution and for me to put work into. Just because it’s open source and I CAN maintain it for us doesn’t mean I’m happy about having to do it
I just had a look and you are right, all of the issues I remembered are duplicates. We still have the problem in our installation but we use a fork of the director because of something to do with baskets.
1 Like
Thanks for the clarification. Our CLA permits that as well. Though, I can assure you that Icinga 2, Icinga Web 2 and all existing modules for it (basically all existing features and extensions) won’t go into this direction. There is already plenty of similar mindset in our team that prevents that. The CLA is just as broad as possible, so you could call us lazy, maybe.
1 Like