Skip to Main Content
Integration


This is an IBM Automation portal for Integration 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).


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 May 2, 2025

ILMT Playbooks with big inventory

In our organisation over 10,000 servers are reporting to ILMT, it does consists of different OS, Regions etc. But the inventory that we use to collect results for ILMT consists over 4000 servers. The problem (although technically it is not a problem as the playbook is working in almost most of the cases and the right data is being exported to the lmt_server) is that the playbook runs for very long(approx 9 or 10 hrs) on the inventory. 

We have often noticed a time out issue on the job as well when it runs over 24hrs, specially for windows regional servers. We have even raised few IBM tickets as well in the past, when manually ran, issue resolves.

 As we use Ansible Automation Platform (AAP) and it have some mechanics build in which can mitigate these problems. Ideally, you want to implement a method whereby you can split your inventory in (equal) pieces. One way to achieve this is to implement serials in the header of your play / playbook. See the documentation regarding serials: Controlling playbook execution: strategies and more — Ansible Community Documentation.

The Automation Platform also has a mechanic built in with a similar feature namely job slicing.When setting this number, multiple jobs are being started in AAP (the amount is based on the value of job slicing if enabled). The inventory will be equally split as well.

Unfortunately, both options do not work with the lmt_collect_results playbook. The playbook consists of several play whereby the last play has the “lmt_server” hard-coded in the header of the playbook. This means, the lmt_server must always be present in the inventory. If you split the inventory, the lmt_server will also be part of the hosts which are being split. For instance: if you configure job slicing to be four, three out of four jobs will fail because the lmt_server is not available hence the data cannot be exported. 

 Hence to summarize our issue:

  • The lmt_collect_result does not support job slicing / has no serial build in.
  • Therefore, we cannot split out inventory.
  • With large inventories (our inventory is over 3k in size) it is not best practice to perform on playbook once in terms of efficiency, resource utilization and playbook execution.
  • We would like to see the lmt_collect_result playbook to be able to be compatible with job slicing if possible.

It would be nice if IBM ILMt playbooks can incorporate these adjustments to be more efficient on larger inventories for organisation like us.

 

Thanks in advance.

Idea priority Low