First Party Infrastructure Tooling
Two pronged question.
First Ansible:
I see what appears to be an official first-party Ansible galaxy collection from Zabbix here with the collection name of `zabbix.zabbix`, and this appears to have been started around April of 2023.
However I also see an "official" (from the perspective of the community namespace), galaxy collection for Zabbix here, dating back to March of 2020 when it was forked off of the ansible core 2.9 code base.
It seems really duplicitous to have multiple efforts for what is roughly the same desired outcome.
Wouldn't it make more sense, assuming Zabbix wants to provide this tooling for its community, for Zabbix to contribute and steer the `community.zabbix` collection, and help keep it up to date in advance of new releases, API changes, etc?
Second Salt:
While Salt Project/Saltstack doesn't have quite the market or mind share as Ansible, it is still in use by plenty.
Salt is in the process of doing a similar transition of moving the zabbix modules out of the bundled package, and into a separate community maintained repo, as documented in this issue, which points to the new repo for the extension here.
I'll be the first to say, there have been a large amount of issues with the salt state and execution modules, mostly newer versions breaking older api methods, and then never getting fixed.
This seems like the perfect opportunity for Zabbix to help steer the community salt-extension roughly from inception, and help maintain it with the community going forward to help make the zabbix experience better for everyone.
Just being able to handle host[group]/action/template/media assignments and it work correctly would be a huge help.
Extending it down the road to support reactors in the way that Event Driven Ansible was added to/with `zabbix.zabbix`.
I'm sure others will have opinions, but I view this as a rising tide lifts all ships situation.
And reducing friction in the zabbix ecosystem leads to more and better adoption, where as things getting stuck in deprecated/changed API purgatory either leads to delayed upgrade cycles or worse, moving to something else.
Curious to hear what others think.
First Ansible:
I see what appears to be an official first-party Ansible galaxy collection from Zabbix here with the collection name of `zabbix.zabbix`, and this appears to have been started around April of 2023.
However I also see an "official" (from the perspective of the community namespace), galaxy collection for Zabbix here, dating back to March of 2020 when it was forked off of the ansible core 2.9 code base.
It seems really duplicitous to have multiple efforts for what is roughly the same desired outcome.
Wouldn't it make more sense, assuming Zabbix wants to provide this tooling for its community, for Zabbix to contribute and steer the `community.zabbix` collection, and help keep it up to date in advance of new releases, API changes, etc?
Second Salt:
While Salt Project/Saltstack doesn't have quite the market or mind share as Ansible, it is still in use by plenty.
Salt is in the process of doing a similar transition of moving the zabbix modules out of the bundled package, and into a separate community maintained repo, as documented in this issue, which points to the new repo for the extension here.
I'll be the first to say, there have been a large amount of issues with the salt state and execution modules, mostly newer versions breaking older api methods, and then never getting fixed.
This seems like the perfect opportunity for Zabbix to help steer the community salt-extension roughly from inception, and help maintain it with the community going forward to help make the zabbix experience better for everyone.
Just being able to handle host[group]/action/template/media assignments and it work correctly would be a huge help.
Extending it down the road to support reactors in the way that Event Driven Ansible was added to/with `zabbix.zabbix`.
I'm sure others will have opinions, but I view this as a rising tide lifts all ships situation.
And reducing friction in the zabbix ecosystem leads to more and better adoption, where as things getting stuck in deprecated/changed API purgatory either leads to delayed upgrade cycles or worse, moving to something else.
Curious to hear what others think.