1.10.0 Release

[oscerd]

We need to release a new version based on Camel 3.18.0 LTS.

What are the issues you want to add as mandatory in 1.10.0? Please add the issues here, so we can track and start a release soon.

[tadayosi]

There are a few open issues that are supposed to be in 1.10.0:
https://github.com/apache/camel-k/milestone/35

I think these three issues are just waiting for a new Camel K runtime release before getting merged:
#3376
#3373
#3317

The other issues are probably OK to postpone to 1.11.0 if there are no objections.

cc: @christophd @claudio4j @squakez @essobedo

[oscerd]

I could start a release for camel-k-runtime and camel-kamelets

[oscerd]

So we can point to staging repository.

[tadayosi]

Probably we should include this to 1.10.0 as well: #3552
cc: @astefanutti

[oscerd]

#3561

For alignment

[oscerd]

I'm releasing again camel-k-runtime as staging repository because of apache/camel-k-runtime@857ec9a

[oscerd]

What's the general situation for releasing?

[christophd]

#3376 is ready to be merged IMO

[oscerd]

#3376 Merged.

[christophd]

@claudio4j has already rebased #3373

It is hard to say weather failing CI jobs are due to changes or general flaky nature of tests. at the moment CI jobs are not very stable

[oscerd]

I think it is failing also because the staging repository is not updated on that branch.

[squakez]

#3317 has several tests failing. I'm having a look to understand why this is happening.

[squakez]

I noticed they are all the same errors happening on the main branch. In particular I can see:

org.graalvm.polyglot.PolyglotException: java.lang.IllegalStateException: Duplicate language id regex. First language [Language class com.oracle.truffle.regex.RegexLanguage, Loaded from file:/deployments/dependencies/lib/main/org.graalvm.regex.regex-22.1.0.jar]. Second language [Language class com.oracle.truffle.regex.RegexLanguage, Loaded from file:/deployments/dependencies/lib/main/org.graalvm.regex.regex-22.1.0.jar].

I think we either merge everything and solve on main or we solve on main, then rebase every pending PR and see each result. I'd go with the second approach which look safer.

[squakez]

Relates quarkusio/quarkus#27085

[claudio4j]

#3373 fails are timeouts.

[tadayosi]

I've pushed remaining ones to 1.11.0 milestone. Now it's only #3373 that we are waiting to be merged.
https://github.com/apache/camel-k/milestone/35

[oscerd]

I re-released camel-k-runtime and updated the staging repo in main branch. We just need to wait for #3373

[squakez]

Listing here the tests I can see are still failing:

• All test local --> fixed by fix(e2e): local test when staging #3574
• Common tests (due to 2.11.0.Final Quarkus core dependency bug) --> Should be fixed by fix: issue inherited by Quarkus platform camel-k-runtime#878
• --- FAIL: TestKitKnativeFullBuild (613.55s)
• --- FAIL: TestOperatorUpgrade (286.91s)
• [test-kamelet-cc3hvcg61tss6ro81ao0-98r28 test-1] INFO | Kamelets templates can use beans ............................... FAILED
• [test-kamelet-no-props-cc3i7lo61tss6ro81arg-7bp28 test-1] INFO | Bind Kamelet to service ........................................ FAILED

[squakez]

Local testing are failing because the E2E is not using the staging repo. I'm working to see if it is easy to include it when present in the Makefile.

[squakez]

Knative tests seems to be resolved in https://github.com/apache/camel-k/runs/8011632479?check_suite_focus=true

[squakez]

I've just verified that the common is still failing as the runtime still uses the bugged quarkus dependency (ie, dependencies/lib/main/org.apache.camel.quarkus.camel-quarkus-js-dsl-2.11.0.jar). I am checking why this is happening.

EDIT: camel-quarkus and quarkus platform may be different, so, the problem may not be here.

[christophd]

I have had a look at the YAKS E2E tests and optimized with using a global operator: #3573
This also seemed to stabilize the tests and reduces the job execution time a lot

[squakez]

I finally manage to workaround the latest standing issue in the common check. Hopefully once this got staged, we should have a green flag to go :)

[oscerd]

I released a new staging release for camel-k-runtime and updated in camel-k with f44b544

[squakez]

Okey, in common check, we've solved some of the errors, but still others are there [1]. I'm listing them here:

• --- FAIL: TestKameletBinding/test_error_handler/throw_error_test (165.07s)
• --- FAIL: TestBindingWithImage/run_with_initial_image (2.44s)
• --- FAIL: TestErrorHandlerTrait/Run_errored_integration_with_error_handler (164.55s)
• --- FAIL: TestHealthTrait/Readiness_condition_with_stopped_route (756.85s)

@lburgazzoli I understood lately we changed something in the error handler. Any hints on places where we should look at by any chance?

[1] https://github.com/apache/camel-k/runs/8064025483?check_suite_focus=true

[lburgazzoli]

Okey, in common check, we've solved some of the errors, but still others are there [1]. I'm listing them here:

* [ ]      --- FAIL: TestKameletBinding/test_error_handler/throw_error_test (165.07s)

* [ ]      --- FAIL: TestBindingWithImage/run_with_initial_image (2.44s)

* [ ]      --- FAIL: TestErrorHandlerTrait/Run_errored_integration_with_error_handler (164.55s)

* [ ]      --- FAIL: TestHealthTrait/Readiness_condition_with_stopped_route (756.85s)

@lburgazzoli I understood lately we changed something in the error handler. Any hints on places where we should look at by any chance?

I don't think we made any change yet to the error handler, or at least not something I explicit recall, do you have any pointer ?

[1] apache/camel-k/runs/8064025483?check_suite_focus=true

[squakez]

@lburgazzoli you're right. I was mislead by this commit where you fixed some log comment only.

[astefanutti]

The format of the health probe has changed with the Camel upgrade, from something like map[route.context.name:camel-1 route.id:route1 route.status:Stopped] to map[check.kind:READINESS route.id:route1 route.status:Stopped]. The e2e tests assertions should be updated accordingly, and the integration monitor action might have to be adjusted as well. @davsclaus can probably provide some more insights on what change on the Camel side.

[tadayosi]

@squakez @astefanutti Thanks for your input. I can take care of TestHealthTrait fix.

[squakez]

@lburgazzoli you're right. I was mislead by this commit where you fixed some log comment only.

After all, my memory is not in that bad shape... I dug a bit more and indeed there was some change in the Error Handler managment in Camel 3.17. This one introduced a regression on Camel K runtime, as one supporting method was wiped off. In order to fix this, we'll probably need to reintroduce a workaround we had in place for pre 3.10 Camel releases. Without that check, there is no way we can verify if a default error handler, as the getErrorHandlerFactory() is in charge to create one, when it is called.

I'll test it locally to see if it works and report how it goes.

fyi @davsclaus

[oscerd]

What's the situation? Do we need another staging release?

[squakez]

What's the situation? Do we need another staging release?

I'm still testing the fix on the camel-k-runtime. We'll probably need a new one. I'll let you know once everything is tested locally.

[oscerd]

It seems only testBindingWithImage is failing now. Do we want to release or do we want to fix it?

[tadayosi]

@oscerd It must be just an issue with the test code. Should be fixed here: #3590 The other failure in install-it CI is also a test code issue #3583. I think it's good to proceed to release.

[oscerd]

If we all agree I'll try to start the release today.

[oscerd]

Started release process.

[oscerd]

The release is on vote.

[zhaojinxin409]

@oscerd Will #3285 be included? Camel-K use almost all resource of one api-server's node because of it.

[oscerd]

Yes, it will.