This is an IBM Automation portal for Cloud Platform 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 (https://ideas.ibm.com).
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:
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 an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
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.
See this idea on ideas.ibm.com
Add the functionality to have the Console choose whether a job should run on a given Server based on the current CPU load of the box hosting the agent. Right now some built-ins allow getting CPU load info, however, that info is gathered only at the time the manifest is refreshed.
If the manifests could be refreshed for a selected group of Servers at the time a job is to execute then the CPU load info could be used to determine which box has the CPU load available to run the job.
It is not feasible to have the manifest refresh run on every Server object say every two minutes to get the CPU load info as we have ~ 160 Server objects.
Idea priority | High |
RFE ID | 29956 |
RFE URL | |
RFE Product | Rational Build Forge |
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.
As part of the review process, we strive to be transparent about our intentions with each enhancement suggestion. The offering team has carefully reviewed this idea and has decided that it does not fit into our current plans or the age of the RFE suggests it is outdated or has been delivered over the time, so the idea will be closed. The idea will be kept in IBM's ideas repository and may still be voted on. It might be reassessed or reopened for additional feedback in the future. We value your feedback and thank you for allowing us the privilege of partnering with you in developing our products.
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - WebSphere
Product family - Application Platform
Product - Build Forge
For recording keeping, the previous attributes were:
Brand - Rational
Product family - Product & application lifecycle management
Product - Build Forge
Feature prioritized, This feature will not be in the next release, but we will give strong consideration for the following release.
This RFE is consistent with our strategy and product roadmap and IBM is continuing to evaluate.
Hello, thanks for the update. One thing I forgot to mention is we hard code our Selectors, which means one Selector = one Server object. It would be very useful to have a BuildForge feature that checks if the box is too busy to start the job and if it is then log a message stating something like "the box is too busy to run the job" as "Selector cannot choose a Server" is cryptic and very generic to end users and BuildForge admins.
Question - Can we get a feature added to return "the server is too busy to run the job" or something similar? We don't need the rest of the manifest info most of the time. We do need BuildForge to tell us when the box is too busy to run a job. I have to login to the box and run a top command to find that info myself which is a time waster as BuildForge can get that info for us - the problem is that the feature to do it does not exist.
Thank you for your information. In fact, it is a balance between performance and accuracy when we designed this feature. If the information collection is trigerred by job execution. Once many jobs are executed in a short time, the network traffic cost will be huge and in most of cases, the information is duplicated. That's the reason we have a system parameter to collect server information periodically (default is 120s). Welcome to have more discussion with me.