Zabbix 7.0 compatibility

[BGmot]

There is a substantial amount of changes that need to happen to make this collection compatible with Zabbix 7.0. Zabbix 7.0rc3 has been released and I suppose it is literally days left before 7.0.0 release. So the code should be stable already I am starting to work on modules compatibility.

If anybody feels like working on roles please create new issue and you are more than welcome to start -)

Let's do it!

[pyrodie18]

I'll take a look at roles in the coming days.

[pyrodie18]

@BGmot do we want to do a final release of what we have now and then start to pull in changes for 3.0?

[BGmot]

@BGmot do we want to do a final release of what we have now and then start to pull in changes for 3.0?
I think yes and the next release would be a major one 3.0, if I recall correctly we have some pending breaking changes.

[pyrodie18]

ya. OK. I'm headed out for the night but will cut a release in the next day or two and then we can start to bring in breaking changes.

[pyrodie18]

@eb4x I know you had some breaking changes. Once I cut the next release if you want to put the PRs back in.

[pyrodie18]

Ok 2.5.0 has been released. Let the breaking changes begin.

[eb4x]

@eb4x I know you had some breaking changes. Once I cut the next release if you want to put the PRs back in.

That would be the idea of splitting out the code for setting up official zabbix repos that repeats in all the roles I suppose? So all roles are more focused on doing their thing, and they can all reuse a new zabbix_repo role to do the initial package repository setup.

The others I think you kinda merged already? requiring python3 for centos7 was probably the only "breaking" change, and maybe the selinux fixes where the sebooleans can actually revert.

I've got some preliminary work on zabbix_web in #1235 , but have other priorities out next week. Will get back to it after.

[pyrodie18]

I'd actually forgotten about splitting out the repo setup. I could kind of go either way on that one. What are your thoughts @BGmot . The one that came to mind was ditching Centos 7

[BGmot]

Having a role to set up the repo is a good idea in my opinion (I don't like duplicating code, when you need to fix an issue you need to fix the same issue in several places).
Centos 7 is not relevant any more I think so I am with you on ditching it.

[pyrodie18]

Do we want to call the setup role from within the main role so it always runs, or document it and leave it to the user to run it first?

[BGmot]

I think it's better to have it within the main role.

[BGmot]

So Zabbix 7.0 has been released.
I've updated/added/tested all the modules for compatibility with 7.0 using my own built containers with 7.0.0rc3. Now I can push my changes upstream to use official Zabbix docker containers.
@pyrodie18 in terms of roles:

1. Have you tested all of them with 7.0?
2. Can you please review all parameters added/removed by 7.0 for config files (server, proxy, agent)?

[BGmot]

Also they dropped support for (Zabbix server):

• Debian 10, 11
• Ubuntu 18, 20

What do we do?

[lzadjsf]

Zabbix server have to be deployed at the latest avaliable software. Agree with them.
Meanwhile agent support for legasy software have to be in place due to sometimes migration of app at legacy infra almost not possible...

[marekvesely-direct]

@BGmot when will be release of your pull request? :)

[BGmot]

@BGmot when will be release of your pull request? :)

When we adapt all the roles -)

[pyrodie18]

@BGmot do you still have more work to do on modules or are you good to go? What else needs/wants to go into 3.0?

[BGmot]

I am done with modules (for now - all current modules are compatible with 7.0)
What else? Probably review and merge PRs that are “almost ready” ro be merged.

[pyrodie18]

Got anything in mind?

• Windows agent installation. #1139 needs to be updated to fit the new format of the agent role and in all honesty I don't totally follow what its doing.
• feat: support zabbix installation on suse #1194 if you want to we can probably pull it in with a little bit of work.
• define postgresql_privs due to priv deprecated in postgresql_user module | Zabbix Proxy #1215 can probably sit down and figure it out.
• Refactor zabbix web #1235 @eb4x what's the status of this?
• zabbix_agent - Use zabbix_agent_distribution_release to backport packages #1240 I still don't see what is trying to be done here and it will definitely break right now.

[eb4x]

I'll rebase #1235, so what is there can be merged.

I haven't got the dependency details on why we're installing additional packages for debian, and what the corresponding should be on redhat quite right yet. I'm currently looking into it, hopefully with some results this weekend.

[pyrodie18]

In the agent role we're taking care of people who are still using zabbix_agent2* variables and setting them properly. Do we want to go ahead and remove that since we got rid of all of them?

[eb4x]

@pyrodie18 Why the change to php-remi?

[pyrodie18]

you're talking about for Rocky8 @eb4x ?

[eb4x]

you're talking about for Rocky8 @eb4x ?

Yeah, any EL8 really. I see zabbix7.0 has a minimum of php8.0, but isn't the appstream for php:8.0/common good enough?

[pyrodie18]

does 8 have php8.0? When I was googling it everything showed having to use remi. Updating a clean dev rock8 VM that I have right now to look at it.

[eb4x]

Yep, dnf modules list gives

php                  7.2 [d]         common [d], devel, minimal
php                  7.3             common [d], devel, minimal
php                  7.4 [e]         common [d] [i], devel, minimal
php                  8.0             common [d], devel, minimal
php                  8.2             common [d], devel, minimal

[pyrodie18]

yep, just saw that. Running the change on a branch right now and will pull in in a few

[pyrodie18]

What else do we want to get in here before we push it all? I'll be done with the comments in #1278 (comment) tonight probably. @eb4x has already said we can pull in the web changes. Not sure where we stand with #1194 but also don't think we need to wait for it.

[BGmot]

I pinged the author of 1194 let's see what he comes up with.
Otherwise I think we are good for new release with mentioned by you PRs merged.

[BGmot]

Which one should we merge first?
#1194 (please see comments in this one)
or
#1235

[pyrodie18]

@eb4x says that #1235 is good to go, so gonna go ahead and pull it in.

[pyrodie18]

OK @BGmot if you want to take a look at #1291 I think that's the last breaking change I have. I'm ready to release if you are. Thoughts @eb4x

[eb4x]

I think you're good to do a release. I haven't got any real "breaking" changes for the roles, just refactors and cleanups which can be merged at any time later.