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:
Post your ideas
Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
Post an idea
Upvote ideas that matter most to you
Get feedback from the IBM team to refine your idea
Help IBM prioritize your ideas and requests
The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The product management team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.
Receive notification on the decision
Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.
Ability to limit user's views in RTM to select clusters
Reduces support because users can't flip to other clusters via Cluster drop-down menu to then ask questions about resources and usage or see other information that should only be for users of a particular cluster or why can't they find their infor...
Ability to specify cores or exclusive host for Benchmark job
Currently all benchmark jobs submitted via RTM use 1 core. Also, one cannot specify node to be exclusively used via bsub -x. This allows other jobs to land on same node and thus tainting benchmark numbers
Move away from having to set job_end_logged on every gridjobs and gridpend poller runs
The setting of job_end_logged to 0 every polling cycle can add as much as 100 seconds to every gridjobs or gridpend run. If instead, the poller were to capture the following
SELECT MAX(last_updated) FROM grid_jobs* WHERE clusterid = ?
Provide "bkill -C 'some comment' jobid" Comment Message in RTM's grid_jobs and grid_jobs_finished tables
We will be doing automated killing of workload in 2022, and now that LSF provides the 'bkill -C' option, we would like that Kill message to be stored in RTM for auditing the reasons why jobs were killed by automation.
Based upon the data collected from the 'gridperf' binary, keep a table of events type type 'mbdreconfig' & 'mbdrestart' and present in RTM
This is important as we don't often time capture a restart or a reconfig, it could even be as a result of a binary that is segfaulting and being restarted by LIM. It would be nice to be able to track these similar to the table below:
RTM's gridparams binary misses many 'bparams -l -a' options
It's important for cross cluster auditing that the RTM system includes all 'bparams -l -a' output. Today, there are several of these options that are not captured making the auditing of cluster configuration via RTM incomplete.
Having written the...
Allow Mass Changes of Both License Services and Clusters
In Cacti at page Console > Management > Devices, you have a dropdown option to "Change Settings". From here, you can select multiple devices, and then change select settings. It would be nice to be able to make these same changes for RTM obj...
Today, on many Cacti pages, table headers include tooltips that explain the dimensions that are displayed in the table. It would be nice to have that for the 13 standard load indexes in LSF, and be able to pull the description from lsf.shared for ...
Allow RTM to define the level of pending reasons to collect
Currently RTM does not provide any pending reason precision to be collected. As such, in our case, there are way to many pending reasons in the system which makes the feature unusable. We would like to have a global setting that does the following...
Currently RTM contains quite a bit of information on current cluster state, but it provides limited information about the state of the scheduler, what job buckets exists, and the dispatch rate from these various buckets. Create an interface that p...
Do not place IBM confidential, company confidential, or personal information into any field.