-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade to Quarkus 2.14.0.CR1 #673
Conversation
This comment has been minimized.
This comment has been minimized.
The platform situation is pretty bad:
So one of the issue is that we don't enforce the old Jandex version in the quarkus-bom anymore so Jandex is actually downgraded to 2.4.0.Final where it's used. As for the Operator SDK issue, it's probably an issue with the new Kubernetes Client and we will need an upgrade. |
/cc @ppalaga @jamesnetherton @zbendhiba for the Camel issues: we need Camel Quarkus to be upgraded to use the new Jandex artifact ( /cc @Naros same for Debezium ^ /cc @metacosm for the Operator SDK upgrade. |
Note that this is for your awareness so that you know that this needs a fix when Quarkus Core 2.14.0.Final core artifacts will be available. |
This comment has been minimized.
This comment has been minimized.
For the operator SDK extension, I was waiting for this release to be able to merge the changes needed (which currently live in the |
Hi @gsmet, I'll give a look. Should I send any extension changes in a separate PR and you'll rebase here? |
QOSDK main branch is now switched to use 2.14.0.CR1 so things should be fixed for the Java Operator SDK extension now. |
Could you release a CR @metacosm to integrate into the platform (branch)? |
I was afraid you'd say that 😉 |
Hi @aloubyansky @gsmet, I'll check with my project lead to see when we can cut a new release of Debezium. We just cut 2.0.0.Final last week and we normally operate on a 3-week cadence, but I'll see if we can potentially cut a 2.0.1.Final earlier to satisfy the Quarkus platform release. I should know something mid-day European time tomorrow. |
Normally we'd release the final version in a week but given the situation we should probably give more time for the members to adjust @gsmet? |
Hi @aloubyansky @gsmet so when I used 2.14.CR1, we got the following error in one of our tests:
Now I tested upgrading from 2.11.0.Final to 2.12.0.Final, 2.13.0.Final, and 2.13.3.Final and all of those upgrades went smoothly. Can either of you point me to what could be causing this problem? The full stack trace is:
Ironically tho, we do have UPDATE This seemed to happen due to a conflict in the io.netty version used between our Pravaga module and our parent BOM where we are strictly limited to 4.1.78.Final for Netty but it seems that Quarkus has moved to 4.1.82.Final as its baseline. We'll discuss this internally to see what we can do to address this. |
The problem, at least in the case of the QOSDK extension, is that there's a sort of cyclic dependency: the extension cannot be released before the appropriate Fabric8 Kubernetes Client version is available in Quarkus. Since the client updates tend to be merged relatively late in the release cycle, this makes it complicated to make any sort of progress on the QOSDK extension in the mean time but then the platform now depends on the extension being released as well so 🤷🏼… Not sure what's the best way to proceed here, actually… |
Looking at the stack traces above: The Camel issue ( The Debezium issue ( |
Also, if anyone has a Jandex-related problem, please ping me anytime (in European working hours :-) ) and I'll be glad to help. |
QOSDK 5.0.0.Beta1 has been released and should be used in this PR. |
I disabled the Camel Quarkus tests and Debezium tests for CR1 and will proceed with the release. |
@Naros so as for DBZ, once Quarkus core 2.14.0.Final is released, we would need an updated DBZ extension based on Quarkus 2.14.0.Final and using the new Jandex artifact i.e. |
Understand @gsmet, that shouldn't be a problem. |
No description provided.