Skip to Main Content

This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Created by Guest
Created on Feb 17, 2023

Remove requirement to have a unique license value for every minor version of ACE image on CP4I

We are trying to setup a lifecycle process for upgrading ACE image run by the ACE integration server pods on CP4I on Openshift in our production environment.

In order to have a smooth cutover/upgrade an Integration server pod to a higher version of the ACE image, we would have to modify the "license:" value and "version: " value in the IS yaml which is unique for every version of ACE including the minor versions (an example of IS yaml is attached). This has the following consequences for us:

  1. We would have to first upgrade the ACE operator to pick up the new version and its license value which needs approvals in a production setup in our enterprise, especially as it may also upgrade other operators due to inter-operator dependency and if the process involves a restart of the pods it requires approval from business.

  2. Our CI/CD pipeline uses ArgoCD to sync IS yaml changes, we would need custom code to lookup the new license value from somewhere each time we would need to upgrade ACE image version in an integration server pod.

  3. Complicated process which otherwise could have been quite simple if it kept the same license value for all minor versions of ACE v12.x (for example and should ideally have the same license value).

  4. We do not understand the significance of having a "version:" field in the IS yaml since we use custom ACE image, the version would anyway show up when the image is booted by an ACE Integration Server pod. Removing it will really make our upgrade process quite simple as we then do not have to make ANY changes to the IS yaml while instead changing the custom ACE image underneath.

We understand its a requirement from IBM legal to accept a specific license appropriate to the level of software. May be it is possible to remove the "license" field and have a license key fixed on the ACE image (retrieved by running "mqsiservice -v" on the pod) which can be programatically read when the pod is run or something?

Idea priority Urgent
  • Admin
    Andy Garratt
    Feb 23, 2023

    Hi Abu, thanks for this - we're looking at options around this. Is it just for ACE or does this also impact other cloud pak components e.g. MQ?

    2 replies