Cautionary Tale 1: Migrating Java applications to Fuse 7.8

This dear reader is a disaster story; a nightmare before Christmas. But one with a happy ending that hopefully will spare you some time if you have to face the same scenario. It is about a Fuse 7.8 migration. And it started the way all cataclysms begin; our Openshift environments were updated with the latest patch, which at the time was 4.5.22, and all of the sudden we could not deploy anything. This was done off course close to the end 2020 (what a great year!) and it jeopardised all the new releases that were expected to be deployed before 2021. Also, we didn’t want to go on Christmas holiday fearing that nothing was working and that we may have to redefine our CI/CD process from scratch.

Fortunately for us, Fuse 7.8 got released in December and with it a new version of the Fabric8 plugin. So there was hope. But also a lot of work ahead of us because we experienced some problems. Here is how we solved them:

Problem 1: Failed to create Route from…

In the newer releases the version from the route API has changed from “v1“ to “”. So the first step involved updating all the route.yml files with the new API version. This was pretty straightforward.

Problem 2: We could not build using maven.

This is a problem all maven users know and hate. We could not deploy because some dependencies could not be resolved:

The following artifacts could not be resolved: io.swagger:swagger-core:jar:1.5.24.fuse-780022-redhat-00001, io.swagger:swagger-annotations:jar:1.5.24.fuse-780022-redhat-00001, io.swagger:swagger-jaxrs:jar:1.5.24.fuse-780022-redhat-00001: Failure to find io.swagger:swagger-core:jar:1.5.24.fuse-780022-redhat-00001

The problem is that the Swagger dependencies are broken. The good news is that Redhat is working on fixing this. So maybe it will be already be solved by the time you read this. But if the problem persists you can add this dependencies in your pom as a workaround:


Problem 3: Hooray it deploys ! ..  but it crashes

The following pictures say it all:Pod crashed


pod crashes detail

The new plugging creates an init container  that changes the permissions of the mounted drives by executing “chmod 777”. This was failing in our environment and because of that, the pod was not starting. Fortunately, you can deactivate the fmp-volume-permission enricher in the pom:


Problem 4: It is time to migrate to Spring Boot 2.

We were using Spring Boot 1 all this time, but with Fuse 7.8 it is no longer possible. Maven will gladly tell you about all the methods that doesn’t exist anymore, deprecated libraries and classes. Even though we had to change several classes and configurations properties, we didn’t face any runtime problems. And I hope we are not in for a surprise.

Problem 5: It compiles! It deploys! It runs! … but it doesn’t redeploy.

The happiness of seeing the pod finally deployed and running faded away after noticing that redeploying was not working. We didn’t get any errors; the build pod was still being created but the old pod continued on being executed. There was no trace of a new deployment pod being created. Turns out, the generated openshift.yml created an incomplete “trigger” section based on the deployment.yml. Fortunately, the solution is pretty simple. Add the following property in your pom:


After that you will get a nice trigger section like this one:

- type: "ConfigChange"
- imageChangeParams:
    automatic: true
    - "spring-boot"
      kind: "ImageStreamTag"
      name: "test-queue-caller:latest"
  type: "ImageChange"

Problem 6: Fabric8 is deprecated and will be obsolete.

The Fabric8 maven plugin is not being updated anymore. A new project called JKube has emerged and will take over the functionality. It is still unknown when Redhat will adopt it and integrate it for with Fuse. But it will eventually come and with it, another migration that hopefully doesn’t involve so many changes.

Fuse 7.8 migration: The Happy End

And so, after all these changes we got our deployment process back running. It has taught us a lot of things about the product and the plugin itself. And also, apart of the famous (or infamous ) “Don’t deploy on Friday” we have now our own new slogan “Don’t patch just before Christmas”.