This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. 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
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
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.
IBM Employees should enter Ideas at https://ideas.ibm.com
Reading more, I see what is going on. I read that the user has modified the lsb.users to include a user or group within the configuration, and reconfig's will issue a warning that the user no longer exists in the system. If that's the case, then the request would be for badmin to ask if they simply want LSF to remove the user from the lsb.users file using the Live Config API. They would still have to eventually merge the modified configuration file. So, there is work required on the part of the user in any case.
Oh, I see the content. Thanks for Tony adding that. So, the title of this would be for LSF to more frequently update it's user and group cache. Today, LSF will rebuild the user and group cache automatically on a frequency if set. But this is for EGROUP and not necessarily OS Groups. The the request should be to simply extend that cache interval to OS Groups, if it's not there already. It's basically a sssd caching like implementation for LSF.
Paul, not everyone has access to the support case. Can you type in the comments some more details about this case?
The background is when an OS user is removed in system, associated default OS user group should be removed. LSF works well to deal with the scenario. Now in client case, when an OS user is deleted, the associated default OS usergroup keeps as before for accounting/tracking purpose (a meaningful user case), LSF looks not cover such scenario well and causes the configuration verification error.
In summary, from client point of view, it's a design flaw/defect, since client cannot remove a user from LSF usergroup via supported LSF function. From dev point of view, it is a valid usercase and is a new functionality -- when reconfiguring the cluster, if related OS usergroup is empty, it needs to remove usergroup from LSF instead of keeping as it is. So RFE is logged for this purpose.