community.zabbix
community.zabbix copied to clipboard
[Discussion] Develop Zabbix Collection 2.0.0
SUMMARY
Begin working on version 2.0.0 of the collection
ISSUE TYPE
- Discussion
ADDITIONAL INFORMATION
I would like to start working on version 2.0.0 of the collection. As I've spent the last week or so going through and adding support for Zabbix 6.2, it's become apparent that there are a lot of skeletons in the code base.
Things I'd like for us to consider doing:
- Only supporting Zabbix 6.2, 6.0, 5.0, and 4.0. All other fixes, hacks and other things that have been inserted into the code base get removed in an effort to clean it up and make it more maintainable.
- Only support currently maintained operating systems. To me, that means anything outside of LTS is retired. Again, remove the hacks and fixes in the code base that are used to maintain those.
- Update the testing matrix. In my opinion, if we're saying we support it (see first to ideas), then we should be testing against it. We clean up the matrix to make it more maintainable.
- I came across the discussions in #567 and #163 . If we want to drop support for something, now is the time to do it. Is that the direction we want to go? Thoughts?
I've created a new project to track this (https://github.com/ansible-collections/community.zabbix/projects/8). Thoughts everyone?
@D3DeFi @ragingpastry @BGmot @lzadjsf @mu1f407
I am all for it. First I think we need to decide what oldest version of Zabbix we want to support.
Indeed, I am also all for this. Would have started this activity a waaay back, but I would have been never been to fully commit.
When it comes to versions, I would drop 4.x as well and only test and support 5/6/6.2
I also think that most of the users run zabbix modules locally or from controller, so enforcing python3.8+ should be easy for us. Ansible-core is also doing the same from 2.14 or such afaik
And for httpapi, if anyone is willing to deep dive into it and finalize it, we could migrate from zabbix-api. This was the plan anyway in the past
I won't lose any sleep ditching 4. People who really need it can keep using the 1.X branch of need be. I have not looked at httpapi at all so no idea what it would take to finish bringing that only.
Sorry I just don't understand what httpapi is thus will be listening.
It was an initiative from @rockaut to re-use httapi plugin from ansible and replace external zabbix-api dependency with it.
Have a look at #444
I think we can ignore it for now if there will be no-one interested in looking at it. It will not make or break 2.0 release anyway
Proposed supported operating systems (for server, web, and proxy):
Ubuntu:
- 18.04 (End of Standard Support [ESS] April 2023)
- 20.04 (ESS April 2025)
- 22.04 (ESS April 2027
Debian:
- 10 (ESS Jun 2024)
- 11 (ESS Aug 2026)
Centos/Rocky
- 7 (ESS Jun 2024)
- 8 (ESS May 2029)
- 9 (ESS May 2032)
I could see maybe expanding the list out some as it relates to the agents. Thoughts?
I agree with OS matrix
So as I go through and rework some of the older operating systems, I'm having problems with them connecting to the mysql 8.0 server. Because of the change in the default authentication method to caching_sha2_password, some of the older default mysql installs don't support it. I'm playing with the idea of instead installing the current version of the mariadb client instead. Thoughts?
So as I go through and rework some of the older operating systems, I'm having problems with them connecting to the mysql 8.0 server. Because of the change in the default authentication method to caching_sha2_password, some of the older default mysql installs don't support it. I'm playing with the idea of instead installing the current version of the mariadb client instead. Thoughts?
For the CI I don't mind. They should more or less still be cross-compatible, right?
I actually didn't think about just doing it for CI. Let me play with that over the weekend.
This may be of interest https://github.com/ansible-collections/news-for-maintainers/issues/23
Anyway, I am not sure if anyone works on plugins, it would be unfortunate to release 2.0.0 with only role changes
This may be of interest ansible-collections/news-for-maintainers#23
Anyway, I am not sure if anyone works on plugins, it would be unfortunate to release 2.0.0 with only role changes
Honestly hadn't even been tracking that. I'm much stronger on the roles side than modules personally. Did you have anything specific in mind?
I am sorry guys it takes too much time to finish httpapi but yes I am updating all the plugins hope to finish this weekend.
I am sorry guys it takes too much time to finish httpapi but yes I am updating all the plugins hope to finish this weekend.
Dont worry at all. I was just unsure if anyone at all was interested in playing with plugins/modules. I've only remembered you are experimenting with httpapi.
The code is ready but I am stuck with testing https://github.com/ansible-collections/community.zabbix/issues/558
OK, so I've obviously fallen to the wayside on this. I'm sorry (life has been a bit of a shit show lately) and I know the current version of the collection has undergone a fair number of changes (most notably https://github.com/ansible-collections/community.zabbix/pull/822. Because of that, I think I'm going to start a new branch based on the current pull, reapply playbooks that we already updated and see what breaks.
Welcome back @pyrodie18! -) Life is a one big shit show...
OK, so I've obviously fallen to the wayside on this. I'm sorry (life has been a bit of a shit show lately) and I know the current version of the collection has undergone a fair number of changes (most notably #822. Because of that, I think I'm going to start a new branch based on the current pull, reapply playbooks that we already updated and see what breaks.
Yup, don't worry, this is open source :) No one expects you to work around the clock and meet deadlines. Hope everything goes better for you from now on. Welcome back! :)
Just a side note to all. Even now as I only have a look from outside it's cool to see the collection progress because all your contributions. 👍🔥
Sent from Outlook for Androidhttps://aka.ms/AAb9ysg
From: Dusan Matejka @.> Sent: Sunday, February 5, 2023 3:36:07 PM To: ansible-collections/community.zabbix @.> Cc: Markus Fischbacher @.>; Mention @.> Subject: Re: [ansible-collections/community.zabbix] [Discussion] Develop Zabbix Collection 2.0.0 (Issue #774)
OK, so I've obviously fallen to the wayside on this. I'm sorry (life has been a bit of a shit show lately) and I know the current version of the collection has undergone a fair number of changes (most notably #822https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fansible-collections%2Fcommunity.zabbix%2Fpull%2F822&data=05%7C01%7C%7C04174df3ffb643414dd508db07865271%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638112045702542985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yYAN7SNwHBCl8DlcIAbf97P16%2BpGSY6cfcbSuNi9f%2Fo%3D&reserved=0. Because of that, I think I'm going to start a new branch based on the current pull, reapply playbooks that we already updated and see what breaks.
Yup, don't worry, this is open source :) No one expects you to work around the clock and meet deadlines. Hope everything goes better for you from now on. Welcome back! :)
— Reply to this email directly, view it on GitHubhttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fansible-collections%2Fcommunity.zabbix%2Fissues%2F774%23issuecomment-1417978711&data=05%7C01%7C%7C04174df3ffb643414dd508db07865271%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638112045702542985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5DxHyh%2FCwy6JXp8fYt86gbytJhQQ1TvMjS3Qq3%2F1ta4%3D&reserved=0, or unsubscribehttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAADOV6DIKPTSGMFZMVRSFNTWV63FPANCNFSM56PCNBUQ&data=05%7C01%7C%7C04174df3ffb643414dd508db07865271%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638112045702542985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=shFuQ0kCqeGeqWa%2Bml%2BqkFXDywRd61u2p446WyOyyb0%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.***>
Gentlemen, I'm not particularly strong when it comes to the configuration of web servers, especially the PHP part of it. Within the web role, do we need to template php-fpm.conf.j2 (anyone know why its only with Debian?), and the php parts within vhost templates or are they leftover from a time in the past? I don't see anything within the Zabbix documentation itself about needing to configure php (if I am missing something, please link it).
Gentlemen, I'm not particularly strong when it comes to the configuration of web servers, especially the PHP part of it. Within the web role, do we need to template php-fpm.conf.j2 (anyone know why its only with Debian?), and the php parts within vhost templates or are they leftover from a time in the past? I don't see anything within the Zabbix documentation itself about needing to configure php (if I am missing something, please link it).
The only thing I usually adjust in php is time zone
date.timezone = bla-bla
and on Debian it can be in:
# Different places of PHP configuration file
if [ -f "/etc/php5/conf.d/99-zabbix.ini" ]; then
PHP_CONFIG_FILE="/etc/php5/conf.d/99-zabbix.ini"
elif [ -f "/etc/php5/fpm/conf.d/99-zabbix.ini" ]; then
PHP_CONFIG_FILE="/etc/php5/fpm/conf.d/99-zabbix.ini"
elif [ -f "/etc/php5/apache2/conf.d/99-zabbix.ini" ]; then
PHP_CONFIG_FILE="/etc/php5/apache2/conf.d/99-zabbix.ini"
elif [ -f "/etc/php/7.0/apache2/conf.d/99-zabbix.ini" ]; then
PHP_CONFIG_FILE="/etc/php/7.0/apache2/conf.d/99-zabbix.ini"
elif [ -f "/etc/php/7.0/fpm/conf.d/99-zabbix.ini" ]; then
PHP_CONFIG_FILE="/etc/php/7.0/fpm/conf.d/99-zabbix.ini"
elif [ -f "/etc/php.d/99-zabbix.ini" ]; then
PHP_CONFIG_FILE="/etc/php.d/99-zabbix.ini"
elif [ -f "/etc/php7/conf.d/99-zabbix.ini" ]; then
PHP_CONFIG_FILE="/etc/php7/conf.d/99-zabbix.ini"
elif [ -f "/etc/php/7.2/fpm/conf.d/99-zabbix.ini" ]; then
PHP_CONFIG_FILE="/etc/php/7.2/fpm/conf.d/99-zabbix.ini"
elif [ -f "/etc/php/7.2/apache2/conf.d/99-zabbix.ini" ]; then
PHP_CONFIG_FILE="/etc/php/7.2/apache2/conf.d/99-zabbix.ini"
elif [ -f "/etc/php/7.4/fpm/conf.d/99-zabbix.ini" ]; then
PHP_CONFIG_FILE="/etc/php/7.4/fpm/conf.d/99-zabbix.ini"
elif [ -f "/etc/php/8.1/fpm/conf.d/99-zabbix.ini" ]; then
PHP_CONFIG_FILE="/etc/php/8.1/fpm/conf.d/99-zabbix.ini"
fi
What are our thoughts on maintaining support for Epel and "other" installation sources? We're not currently testing against it at all and if we're going to support, I should add it to the testing matrix (not that I'm entirely sure how to test against "other". Dropping it will clean up the code a little bit (although not a ton).
Hello everybody!
As for support of Zabbix 5.0 seems is getting outdated as a question for Collection version 2.*, please see Life Cycle policy https://www.zabbix.com/life_cycle_and_release_policy
@pyrodie18 not sure about Epel, as i'm a bit out of using any RedHat and their forks.
@BGmot If it really have concerns to keep supporting php5? Seems out of support too.
Also, My opinion regarding keeping zabbix not up to date looks as a bad practice due to new versions since 5.4 having too much very useful, interesting and tricky features and things.
Good call. If that's the case then if there aren't any objections, I am going to pull 5.0 from the collection with the 2.0 release. Also maybe consider updating what we advertise as supporting to anything that is still under "Full Support" from Zabbix instead of the current last 2 major releases.
@BGmot If it really have concerns to keep supporting php5? Seems out of support too.
I don't deal with roles a lot but don't mind removing php5 support, it is ancient and I did not even know our role still supports it.
OK so next decision. I'm pretty well done with the updates (sans 6.4 work) with everything except for the agent. Right now we "support" a ton of different OSs (outside of our normal list). Do we want to keep that up, understanding that for at least a few, there's probably not a good way to test this (this includes Windows).
OK so next decision. I'm pretty well done with the updates (sans 6.4 work) with everything except for the agent. Right now we "support" a ton of different OSs (outside of our normal list). Do we want to keep that up, understanding that for at least a few, there's probably not a good way to test this (this includes Windows).
we don't. Unless somebody wants to join in and take on the ownership for the particular OS, we don't support nor guarantee anything. Patches are merged only on best effort basis and we should not feel obliged at all to port the roles for those OSes. It may be worth specifying that we don't support those, but opted to merge patches for them in the past
So what's outstanding items?
- drop zabbix-api support
- clean up roles variables
- decide on what versions of Zabbix/OSs we support and clean up the collection
- ... ?
OK so I have cleaned up (removed all depreciated variables, simplified variables, remove old code fragments, remove tasks out of scope of Zabbix, etc.) all of the roles outside of Agent. I've removed support for Zabbix < 6.0 and all operating systems other than Debian, Ubuntu, and RHEL (supported versions only). The one exception is Windows on the Agent role which we can't test currently). I have not tackled adding support for 6.4 (from the role perspective).
Given the fact that support for 5.0 drops on May 31st, I would suggest that we target that as a no later than release date.