Zabbix constantly releasing new non-upgradeable versions is annoying

[vic]

You did it going from 2.x (was it 2.0 or 2.1, don't remember) to 2.2 which was quite annoying. Now you did it again going from 2.2 to 2.4.

Please stop doing that. These are mostly incremental changes. Make them upgradeable with a simple yum update or stop doing it.

[vic]

Before someone says no big deal. It is a big deal when you have dozens of servers that you have to manually update the zabbix-agent version rpm repo on.

We don't use Puppet or Ansible etc. because we don't need it and don't want to have to install that just to keep up with these constant non-automatic zabbix upgrades which are just incremental updates that could be done with yum update or whatever.

[BDiE8VNy]

What exactly do you mean by non-upgradable?

New Zabbix releases support all previous Zabbix agents. See Version compatibility
Beginning with Zabbix release 2.2 database upgrades are done automatically by Zabbix server on startup. See Automatic database upgrade

The only thing I'm aware of that might become a bit problematic during release upgrade is the Zabbix proxy:

• SQLite3 database is not automatically upgradeable and has to be removed manually to get automatically recreated.
• Release versions of Zabbix server and Zabbix proxy have to match. However, to date it was not a serious issue. Since proxies despite of that were still able to send data to the server - no idea regarding passive proxies though

Edit:
As for proxy 2.2 and server 2.4, see: upgrade to 2.4
As for proxy 2.0 and server 2.2, see: Zabbix 2.2 with proxy 2.0

[vic]

What I mean is that upgrading from v2.2 to v2.4 is a manual process requiring changing the yum repo if one is using repo install. That is the easiest so if you are using something else it is even harder. It's even more complicated if I were to follow the recommendations exactly. Backing up the SQL database, shutting down the daemons etc. I would back up the SQL database anyways but shutting down the daemon is another unnecessary step. Should be done with yum update built into the rpm.

STOP DOING THAT PLEASE!

Going from v2 to v3 where there are major changes ok fine. Not incremental. This is the second time you guys did this in as many years.

Doesn't make sense to have to do it if I were upgrading from CentOS v6.5 to v6.6 and doesn't makes sense upgrading from Zabbix v2.2 to v2.4.

[BDiE8VNy]

I see your point. Anyway, even when such a practice might be beneficial in your use case, I'd argue that it would not be good practice for most users.

Zabbix release numbers are currently not part of the RPM package name. This allows the software continuously to be updated - or upgraded of course, by just switching the software repository.

Zabbix update versions include bug/security/stability or performance related changes without touching the database at all. This ensures that after an update every functionality behaves (hopefully) the same as before the update. Since there are no database related changes, Zabbix can be arbitrarily up- and down-graded within update releases - e.g. by just switching the binaries.

There are several reasons why users might not want to upgrade to the next release. When e.g. using LTS releases only to name only one of them.

An upgrade is almost always connected with database related and functional changes, which may mean expensive operations depending on the change or the respective database engine used.
It can't be foreseen from Zabbix point of view what this or possible other constraints in the respective environment means for a customer.

It's similar with RHEL. It's very unlikely that anything works different after an update. Red Hat tries to port any relevant fix back to the respective version used in its major release. So the functionality of the software widely remains the same, with all the good and the bad, but having issues fixed.

The only way I could think of, when using a static RPM repository is by adding the release version to the package name:
zabbix22-2.2.0-1

This way it's possible to keep a still supported release when a newer version would be available.
But this would likely make the upgrade procedure and possibly other things more complicated than it is now.

Edit:
Btw, why don't you create your own repository? There you could mirror all software from upstream fully automated and never have to change the repository again. See Creating a Yum Repository

[kustodian]

Doesn't make sense to have to do it if I were upgrading from CentOS v6.5 to v6.6 and doesn't makes sense upgrading from Zabbix v2.2 to v2.4.

I don't agree with this. Centos 6.5 -> 6.6 is mostly bug fixes and some improvements which are mostly backward compatible. On the other hand 2.2 and 2.4 are major Zabbix version and upgrading from one version to another should be a manual process. I wouldn't like to see my Zabbix instances upgraded automatically after running 2.2 to 2.4, since that upgrade could break something (especially if you are using partitions for history/trends).

If you have a few dozens of instances of Zabbix you should probably start automating some things, but even if you don't want to use Puppet/Chef/Ansible, you basically need to commands to upgrade zabbix, which isn't that hard. Also I think that 2.4 packages did restart zabbix-agent automatically.

P.S. Issue I had with upgrading from 2.2 -> 2.4.0 was that after I changed the repository to 2.4 zabbix-web didn't want to upgrade, it reported a conflict, so I had to uninstall zabbix-web first and then install the 2.4 version. I think 2.4.1 didn't have this issue last time I tested.

[BDiE8VNy]

For the record, RHEL minor releases x.1, x.2, x.<n>, are just points in time where all previous updates are cumulated to new ISO images.

[BDiE8VNy]

ZBXI-33 asks for a static symbolic link to latest release repository.