IBM Sustainability Software - Ideas Portal


This portal is to open public enhancement requests against the products and services belonging to IBM Sustainability Software. 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.

Add a new idea Subscribe
Status Not under consideration
Workspace IBM MAS - Common Services
Created by Guest
Created on Apr 15, 2026

RELATED IDEAS

Adjust limits for IBM Truststore Manager Operator

We have identified a concern with the default resource configuration for the IBM Truststore Manager in our OpenShift environment, where CPU limits are set significantly higher than CPU requests (e.g., requests of 10m CPU and limits of 5 CPU). 
spec:
  containers:
  - resources:
    limits:
      cpu: '5'
This large disparity leads the Kubernetes scheduler to treat these pods as very lightweight, resulting in dense packing on nodes, while at runtime the pods are allowed to consume substantial CPU resources. Under load, this behavior contributes to CPU contention, elevated load averages (observed load per core exceeding 4), and potential node instability or unresponsiveness. The impact is amplified in MAS deployments, where multiple instances of Truststore Manager are installed by design—specifically three instances for a standard MAS/Manage deployment (MAS Core, MAS Manage, and SLS), with two additional instances introduced for each additional MAS deployment. This results in a multiplied effect of the same resource configuration pattern across the cluster. We recommend aligning CPU requests more closely with actual usage and reducing the gap between requests and limits (for example, setting requests to 500m and limits to 500m–1 CPU) to ensure more accurate scheduling and to prevent node-level CPU saturation. 
The Limits can be adjusted, however this needs to be done for each namespace and everytime the environment is patched it has to be redone which introduces administrative overhead. 

Idea priority Urgent
Needed By Quarter
  • ADMIN RESPONSE
    Jun 8, 2026

    Hi,

    Thank you for taking the time to provide your ideas to IBM. Unfortunately, after evaluating this idea, we don’t believe it aligns with our product strategy and roadmap. Therefore, we will not be considering it for inclusion in our product at this time. Thank you again for your feedback.

  • Post comment
  • Admin
    Andrew Foster
    Jun 8, 2026

    Thanks again for your feedback. Based on the previous information shared, we are closing this idea with no further action.

    Reply
  • Admin
    Andrew Foster
    May 6, 2026

    Across MAS we set low requests based on what the minimum is needed for low/minimal usage, and set limit based on a reasonable peak usage. This allows customers to manage the level of resource contention they are happy with in a cluster by balancing the % of the limit that can be provisioned at one time across all workloads.

    If customers with to run with a guaranteed QoS, we do support that using pod templates, but it's significantly more expensive.

    The numbers stated don't match what is in MAS today. The actual values are:

    • cpu: request 100m / limit 1

    • mem: request 64mi / limit 256mi

    And that is only for the lifetime of the job. While it may well result in the job being scheduled on a node with less than 1cpu available, but unless there's something odd in the cluster, the scheduler would be unlikely to be routing to such a worker unless all workers were similarly overbooked.

    The reason for the high limit is that in some cases customer truststores can be quite large, and we don't want the OOTB config to be an issue.

    The limits can be adjusted permanently by reconfiguring the Truststore subscription, e.g if customer knows they only have smaller truststores and wanted to bring the limits closer to the requests:

    kind: Subscription
    metadata:
      name: ibm-truststore-mgr-1.x-stable-ibm-operator-catalog-openshift-marketplace
      namespace: mas-test-core
    spec:
    ...
      config:
         env:
         - name: WORKER_MEMORY_LIMIT
           value: 128Mi
         - name: WORKER_CPU_LIMIT
           value: "0.5"

    We don't currently have equivalent capability to manage the request value.



    Reply

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.