Bump kafka CRD version to 3.5.0

[mjurc]

Summary

• With updates to Strimzi operator, anything below 3.4.0 does not work. Also bumping this because 1.2.z RHBQ 2.13 branch got bumped to 3.5.0 as Kafka seems to be pursuing aggressive update policy.

Please check the relevant options

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Dependency update
• Refactoring
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update
• This change requires execution against OCP (use run tests phrase in comment)

Checklist:

• Example scenarios has been updated / added
• Methods and classes used in PR scenarios are meaningful
• Commits are well encapsulated and follow the best practices

[michalvavrik]

Why don't we use 3.6 in main as suggested here #923 ? I take it it's because of Ghost? You can only bump to 3.5 in 1.3.z

[michalvavrik]

Also, I'd expect tests to fail, that's why I suggested to do it in one PR, while this one can seem clearer, I suppose you tested it and tests pass.

[mjurc]

@michalvavrik this is not Quarkus/branch dependent, it's just that the Strimzi operator is pushing the version of kubernetes kafka object that it defines forwards.

We can push all branches to 3.6.0, but this is what we tested RHBQ 2.13.8.SP3 with, and I didn't want the rest of branches being behind the oldest branch still supported

[michalvavrik]

@michalvavrik this is not Quarkus/branch dependent, it's just that the Strimzi operator is pushing the kubernetes kafka object version forwards.

I thought there is some client communicating with this Kafka, that's why I asked on compatibility. I understand from your answer it's not a problem.

We can push all branches to 3.6.0, but this is what we tested RHBQ 2.13.8.SP3 with, and I didn't want the rest of branches being behind the oldest branch still supported

I am trying to understand why not to use 3.6 against 999-SNAPSHOT / the latest released version. I think there is ask to be more conservative when bumping tested operators / images in non-feature releases, so I can understand why we would use 3.5 in 3.2 branch, but this PR target main branch.

[michalvavrik]

You know, if you wanted this fixed for main branch, you could just do review #923

[michalvavrik]

I won't pretend this PR is not completely fine. It's just that I though you could hit merge button here #923, but we can go this way. Thanks for the fix.

[mjurc]

@michalvavrik this is not Quarkus/branch dependent, it's just that the Strimzi operator is pushing the kubernetes kafka object version forwards.

I thought there is some client communicating with this Kafka, that's why I asked on compatibility. I understand from your answer it's not a problem.

We can push all branches to 3.6.0, but this is what we tested RHBQ 2.13.8.SP3 with, and I didn't want the rest of branches being behind the oldest branch still supported

I am trying to understand why not to use 3.6 against 999-SNAPSHOT / the latest released version. I think there is ask to be more conservative when bumping tested operators / images in non-feature releases, so I can understand why we would use 3.5 in 3.2 branch, but this PR target main branch.

Just to address this with complete explanation - this is nothing on client side. It's just that the Strimzi operator which tests install is keeping on rolling out new API version for kafka custom resources which are the way to configure Kafka deployment provided by such operator.

I agree we should bump it to 3.6.0 api version, but in all branches. We use the same Strimzi operator release stream for all supported product versions (I am not even sure there's a different operator upgrade stream for Strimzi, tbh).

You know, if you wanted this fixed for main branch, you could just do review #923

Sorry, I didn't get to that yet - I was just running through the backlog of stuff left over to do from 2.13.8.SP3.CR1 - I didn't notice that it included the bump 😅

[mjurc]

run tests

[mjurc]

@michalvavrik I think I'll actually go forwards with merging your MR and close this, thanks for letting me know!

[mjurc]

Closing as this was obsoleted by #923

[michalvavrik]

got it, thanks