Skip to Main Content
IBM Sterling


This portal is to open public enhancement requests for IBM Sterling products and services. 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 (https://ideas.ibm.com).


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 (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Submitted
Created by Guest
Created on Mar 11, 2025

Container Deployments - Use one common prerequisite script

Having one script, that has the same name in each upgrade, that does all the prerequisite work will help cut back on deployment problems. This is especially important with SSP container upgrades. In the FixList.txt there are two scripts to delete the security context and two scripts to add security context.

Looking at the scripts required by SSP install/upgrade, the first is run without flags and the second run using the project or namespace as the flag. The create scripts work the same. These are relatively small scripts. Would it be possible for IBM going forward to add all 4 to one script with one default name/standard name? A script that captures and prints out previous settings, new settings and verifies the project space name. Even if there are no changes that need to be run still have a default prerequisite script that uses the same name each time.

This allows companies/users to create a pipeline that calls the default prerequisite script. A pipeline will track and keep a history of script runs (if they call the same script name) and helm upgrades. The second thing it does is cut back on errors like we experienced with the scripts being executed in the wrong namespace.

If the scripts can't be combined into one default prerequisite script, it would be nice if there was some namespace verification or namespace print out added to scripts. If the scripts can run an "oc project" and have the user verify they are in the proper namespace this would super useful. Preventing errors or problems in an already complicated OpenShift environment.

As our company found out the hard way running scripts that change the security context in the wrong name space can take down applications that need specific permissions to run.

Having one script name to run each time before or after a helm upgrade would cut down on errors. With pipelines you don't have to worry about running the command in the wrong environment because they are project/namespace specific.



What is your industry? Banking
How will this idea be used?

A customer who uses pipeline scripts to run helm upgrades/installs can set that script to call a prerequisite script or post script during the helm install/upgrade. Pipelines are namespace specific and keep track of run history. This cuts down on potential errors that container admins have and tracks anything that happened in case something breaks, and IBM support has to be engaged. Then we can all be on the same page and not have to guess at what happened/what was executed.

Even if one default pre/post script is not used it would be super helpful to have scripts that are run with admin permission to verify the namespace, as a prompt to the user, to prevent configuration errors.