Chapter 2. Upgrading Fuse Online
For OCP 4.x, use the OpenShift OperatorHub to upgrade from Fuse 7.8 to 7.9, regardless of how you installed Fuse 7.8 (by using the install script or the OperatorHub).
For OCP 3.11, use the install script to upgrade from Fuse 7.8 to 7.9.
You should determine whether upgrading to Fuse 7.9 requires you to make changes to your existing integrations. Even if no changes are required, you must republish any running integrations.
2.1. Upgrading Fuse Online by using the OperatorHub (OCP 4.x)
Use the OpenShift OperatorHub to upgrade from Fuse Online 7.9 to 7.10.
- If you want to upgrade from Fuse Online 7.9.x to Fuse Online 7.10.1, you must first manually upgrade to Fuse Online 7.10.0 as described in the Upgrading from Fuse Online 7.9.x to 7.10.1 requires manual upgrade steps release note.
- Fuse Online 7.10 requires OpenShift Container Platform (OCP) 4.6 or later. If you are using OCP 4.5 or earlier, you must upgrade to OCP 4.6 or later, if you want to upgrade to Fuse Online 7.10 .
On OCP 4.9, When you upgrade to 7.10, the following warning is displayed during the Fuse Online Operator upgrade process:
W1219 18:38:58.064578 1 warnings.go:70] extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 IngressThis warning appears because clients (that Fuse Online uses for the Kubernetes/OpenShift API initialization code) access a deprecated Ingress version. This warning is not an indicator of complete use of deprecated APIs and there is no issue with upgrading to Fuse Online 7.10.
The upgrade process from a Fuse Online 7.9 or an earlier 7.10 version to a newer Fuse Online 7.10 version depends on the Approval Strategy that you selected when you installed Fuse Online:
- For Automatic updates, when a new version of the Fuse Online operator is available, the OpenShift Operator Lifecycle Manager (OLM) automatically upgrades the running instance of the Fuse Online without human intervention.
- For Manual updates, when a newer version of an Operator is available, the OLM creates an update request. As a cluster administrator, you must then manually approve that update request to have the Fuse Online operator updated to the new version as described in the Manually approving a pending Operator upgrade section of the OpenShift documentation.
During and after an infrastructure upgrade, existing integrations continue to run with the older versions of Fuse Online libraries and dependencies.
To have existing integrations run with the updated Fuse Online version, you must republish the integrations.
2.2. Upgrading Fuse Online by using the install script (OCP 3.11)
For OCP 3.11, the install script procedure for the following upgrades is the same:
- From Fuse Online 7.9 to Fuse Online 7.10
- From a Fuse Online 7.10 version to a newer Fuse Online 7.10 version
Prerequisites
You installed and are running version 7.9 of Fuse Online on OCP 3.11 on-site OR you installed and are running a version of 7.10 of Fuse Online on OCP 3.11 and you want to upgrade to fresh application images.
For earlier versions:
- If you are running version 7.8 of Fuse Online on OCP, then you must upgrade to 7.9 and then you can upgrade to 7.10.
- If you are running version 7.7 of Fuse Online on OCP, then you must upgrade to 7.8 and then you can upgrade to 7.9.
- If you are running version 7.6 of Fuse Online on OCP, then you must upgrade to 7.7 and then you can upgrade to 7.8.
- If you are running version 7.5 of Fuse Online on OCP, then you must upgrade to 7.6 and then you can upgrade to 7.7.
- If you are running version 7.4 of Fuse Online on OCP, then you must upgrade to 7.5 and then you can upgrade to 7.6.
- If you are running version 7.3 of Fuse Online on OCP, then you must upgrade to 7.4 and then you can upgrade to 7.5.
- If you are running version 7.2 of Fuse Online on OCP, then you must upgrade to 7.3.
- If you are running version 7.1 of Fuse Online on OCP, then you must upgrade to 7.2.
-
You installed the
occlient tool and it is connected to the OCP cluster in which Fuse Online is installed. - You have cluster administration permissions, which are required for the first two steps in this procedure.
Procedure
- To avoid encountering a possible Docker limit error, a cluster administrator sets up access to Docker images as described in Access Docker images before an upgrade.
A cluster administrator downloads the Fuse Online package and grants permission for a user to upgrade Fuse Online in a particular project:
Download the package containing the Fuse Online installation scripts from the following location:
https://github.com/syndesisio/fuse-online-install/releases/tag/1.13
Unpack the downloaded archive at a convenient location on your file system. The
fuse-online-install-1.13directory contains the scripts and supporting files for upgrading Fuse Online.Change to the directory that contains the extracted archive. For example:
cd fuse-online-install-1.13Log in to OpenShift with a cluster administration account, for example:
oc login -u admin -p adminChange to the OpenShift project in which Fuse Online needs to be upgraded, for example:
oc project fuse-online-projectUpdate the Fuse Online custom resource definition:
bash install_ocp.sh --setupGrant permission for upgrading Fuse Online in just this project. For example, the following command grants permission for upgrading Fuse Online to the
developeruser. After the cluster administrator runs this command, thedeveloperuser can upgrade Fuse Online in only this project, which isfuse-online-project, in this example:bash install_ocp.sh --grant developer
The user who was granted permission to upgrade Fuse Online performs the upgrade:
Log in to OpenShift, for example:
oc login -u developerSwitch to the project in which you want to upgrade Fuse Online, for example:
oc project fuse-online-projectTo check which version you are about to upgrade to, run the update script with the
--versionoption, as follows:bash update_ocp.sh --versionInvoke the update script as follows:
bash update_ocp.shTo learn more about the script, invoke
bash update_ocp.sh --help.During and after an infrastructure upgrade, existing integrations continue to run with the older versions of Fuse Online libraries and dependencies.
Upgrade Fuse Online integrations that are running as follows:
- In Fuse Online, select the integration that you want to upgrade.
- Select Edit.
- Select Publish to republish the integration.
Republishing the integration forces a rebuild that uses the latest Fuse Online dependencies.
2.3. Upgrading Fuse Online integrations
When you upgrade to Fuse Online 7.10, you should determine whether you need to make changes to your existing integrations.
Review the Apache Camel updates described in Camel Migration Considerations.
Even if your integrations do not require changes, you must republish any running integrations because during and after an infrastructure upgrade, existing integrations continue to run with the older versions of Fuse Online libraries and dependencies. To have them run with the updated versions, you must republish them.
Procedure
To republish your integrations, in your Fuse Online environment:
- In the Fuse Online left navigation panel, click Integrations.
For each integration:
-
To the right of the integration entry, click
and select Edit.
- When Fuse Online displays the integration for editing, in the upper right, click Publish.
-
To the right of the integration entry, click
Publishing forces a rebuild that uses the latest Fuse Online dependencies.
The Fuse Online user interface shows a warning if any element of an integration has a newer dependency that you need to update.
2.3.1. Camel migration considerations
Creating a connection to MongoDB using the MongoClients factory
From Fuse 7.10, use com.mongodb.client.MongoClient instead of com.mongodb.MongoClient to create a connection to MongoDB (note the extra .client sub-package in the full path).
If any of your existing Fuse applications use the camel-mongodb component, you must:
Update your applications to create the connection bean as a
com.mongodb.client.MongoClientinstance.For example, create a connection to MongoDB as follows:
import com.mongodb.client.MongoClient;
You can then create the MongoClient bean as shown in following example:
return MongoClients.create("mongodb://admin:password@192.168.99.102:32553");- Evaluate and, if needed, refactor any code related to the methods exposed by the MongoClient class.
Camel 2.23
Red Hat Fuse uses Apache Camel 2.23. You should consider the following updates to Camel 2.22 and 2.23 when you upgrade to Fuse 7.8.
Camel 2.22 updates
- Camel has upgraded from Spring Boot v1 to v2 and therefore v1 is no longer supported.
- Upgraded to Spring Framework 5. Camel should work with Spring 4.3.x as well, but going forward Spring 5.x will be the minimum Spring version in future releases.
- Upgraded to Karaf 4.2. You may run Camel on Karaf 4.1 but we only officially support Karaf 4.2 in this release.
- Optimized using toD DSL to reuse endpoints and producers for components where it is possible. For example, HTTP based components will now reuse producer (HTTP clients) with dynamic URIs sending to the same host.
- The File2 consumer with read-lock idempotent/idempotent-changed can now be configured to delay the release tasks to expand the window when a file is regarded as in-process, which is usable in active/active cluster settings with a shared idempotent repository to ensure other nodes don’t too quickly see a processed file as a file they can process (only needed if you have readLockRemoveOnCommit=true).
- Allow to plugin a custom request/reply correlation id manager implementation on Netty4 producer in request/reply mode. The Twitter component now uses extended mode by default to support tweets greater than 140 characters
- Rest DSL producer now supports being configured in REST configuration by using endpointProperties.
- The Kafka component now supports HeaderFilterStrategy to plugin custom implementations for controlling header mappings between Camel and Kafka messages.
- REST DSL now supports client request validation to validate that Content-Type/Accept headers are possible for the REST service.
- Camel now has a Service Registry SPI which allows you to register routes to a service registry (such as consul, etcd, or zookeeper) by using a Camel implementation or Spring Cloud.
- The SEDA component now has a default queue size of 1000 instead of unlimited.
The following noteworthy issues have been fixed:
- Fixed a CXF continuation timeout issue with camel-cxf consumer that could cause the consumer to return a response with data instead of triggering a timeout to the calling SOAP client.
- Fixed camel-cxf consumer doesn’t release UoW when using a robust one-way operation.
- Fixed using AdviceWith and using weave methods on onException etc. not working.
- Fixed Splitter in parallel processing and streaming mode may block, while iterating message body when the iterator throws an exception in the first invoked next() method call.
- Fixed Kafka consumer to not auto commit if autoCommitEnable=false.
- Fixed file consumer was using markerFile as read-lock by default, which should have been none.
- Fixed using manual commit with Kafka to provide the current record offset and not the previous (and -1 for first).
- Fixed Content Based Router in Java DSL may not resolve property placeholders in when predicates.
Camel 2.23 updates
- Upgraded to Spring Boot 2.1.
- Additional component-level options can now be configured by using spring-boot auto-configuration. These options are included in the spring-boot component metadata JSON file descriptor for tooling assistance.
- Added a documentation section that includes all the Spring Boot auto configuration options for all the components, data-formats, and languages.
-
All the Camel Spring Boot starter JARs now include
META-INF/spring-autoconfigure-metadata.propertiesfile in their JARs to optimize Spring Boot auto-configuration. - The Throttler now supports correlation groups based on dynamic expression so that you can group messages into different throttled sets.
- The Hystrix EIP now allows inheritance for Camel’s error handler so that you can retry the entire Hystrix EIP block again if you have enabled error handling with redeliveries.
- SQL and ElSql consumers now support dynamic query parameters in route form. Note that this feature is limited to calling beans by using simple expressions.
- The swagger-restdsl maven plugin now supports generating DTO model classes from the Swagger specification file.
The following noteworthy issues have been fixed:
- The Aggregator2 has been fixed to not propagate control headers for forcing completion of all groups, so it will not happen again if another aggregator EIP is in use later during routing.
- Fixed Tracer not working if redelivery was activa†ed in the error handler.
- The built-in type converter for XML Documents may output parsing errors to stdout, which has now been fixed to output by using the logging API.
- Fixed SFTP writing files by using the charset option would not work if the message body was streaming-based.
- Fixed Zipkin root id to not be reused when routing over multiple routes to group them together into a single parent span.
- Fixed optimized toD when using HTTP endpoints had a bug when the hostname contains an IP address with digits.
- Fixed issue with RabbitMQ with request/reply over temporary queues and using manual acknowledge mode. It would not acknowledge the temporary queue (which is needed to make request/reply possible).
- Fixed various HTTP consumer components that may not return all allowed HTTP verbs in Allow header for OPTIONS requests (such as when using rest-dsl).
- Fixed the thread-safety issue with FluentProducerTemplate.
