IBM MQ needs an official, IBM-supported Ansible Collection for declarative and idempotent administration of MQ objects. This is essential for customers operating under Zero-Touch, Zero-Trust, security, and compliance requirements, where all configuration changes must be controlled through Git, peer review, approval, and automated pipelines rather than interactive host access.
Without this capability, customers must continue to build and maintain their own automation layers. IBM MQ needs to provide this as a standard product capability to remain relevant in modern enterprise platform and GitOps environments.
1. Current State & Pain Points
IBM MQ remains a strategic and highly reliable messaging platform, but its administration model is still too dependent on imperative commands, host access, and customer-developed automation.
Today, customers commonly use `runmqsc`, `setmqaut`, shell scripts, custom Python code, PCF integrations, or incomplete community content. These approaches create avoidable effort and risk:
- `runmqsc` scripts are not inherently idempotent. Customers must implement custom logic to determine whether an object exists, whether attributes differ, and whether a change is required.
- Repeated execution of naïve scripts can fail, produce misleading errors, or create unintended changes.
- Custom solutions must parse MQSC responses, handle exceptions, manage retries, and implement their own state comparison.
- Community automation often covers only installation or basic queue creation, but not the complete operational scope, especially CHLAUTH, topics, subscriptions, and OAM authorization records.
- Manual SSH and console access conflict with Zero-Touch and Zero-Trust operating models.
- Emergency or manual changes create drift between development, test, production, high-availability, and disaster-recovery environments.
- Audit evidence is fragmented when configuration changes are performed through direct host access instead of controlled automation pipelines.
For customers with strict security and compliance requirements, this is no longer acceptable. MQ configuration must be treated as version-controlled infrastructure, not as a collection of host-level administrative commands. As Red Hat is an IBM company, customers naturally expect seamless, enterprise-grade integration between IBM’s premier messaging platform (MQ) and Red Hat’s flagship automation platform (Ansible).
The focus should be on every IBM MQ queue manager running on any supported platform, including z/OS, Linux (RHEL/SUSE), AIX, IBM i, Windows and the MQ Appliance.
2. Proposed Solution & Technical Specification
IBM should provide an official, enterprise-grade Ansible Collection, for example `ibm.ibm_mq`, maintained and supported by IBM and available through both Red Hat Automation Hub and Ansible Galaxy.
The collection should enable customers to define IBM MQ configuration declaratively in YAML files stored in Git repositories. Ansible Automation Platform, AWX, GitLab CI, GitHub Actions, Azure DevOps, or equivalent pipelines should then reconcile the desired configuration with the actual queue manager state.
Required capabilities
The collection should provide full lifecycle management with standard Ansible semantics:
- `state: present` to create or update an object.
- `state: absent` to remove an object in a controlled manner.
- True idempotency: an unchanged desired state must result in `changed: false`.
- Intelligent attribute updates: update only attributes that differ from the declared desired state.
- Structured module output, actionable error messages, and safe handling of administrative credentials.
Required IBM MQ object coverage
The collection should support declarative management of:
- Queues: `QLOCAL`, `QREMOTE`, `QALIAS`, and `QMODEL`.
- Channels: `SDR`, `RCVR`, `SVRCONN`, `CLNTCONN`, `CLUSSDR`, and `CLUSRCVR`.
- Topics, subscriptions, and namelists.
- Queue manager attributes and services.
- Cluster-related configuration where applicable.
- Channel Authentication Records (`CHLAUTH`).
- OAM authorization records for users and groups, as a declarative equivalent of `setmqaut`.
Security and governance objects must be first-class capabilities, not optional additions. In particular, CHLAUTH and OAM configuration are essential for customers operating under strict compliance requirements.
Required connectivity models
The collection should support:
- Local administration: Bindings or IPC mode where automation intentionally runs on the queue manager host.
- Remote administration: Central administration from Ansible Automation Platform or a CI/CD runner through secured MQ Client/PCF connectivity and/or supported IBM MQ Administrative REST APIs.
Remote administration is critical. A modern MQ automation solution must not require administrators to log on through SSH or execute `runmqsc` directly on production hosts.
Required GitOps, check mode, and diff mode support
The collection must support `ansible-playbook --check --diff` for all relevant object types. This must allow customers to validate a pull request before deployment by answering:
- Which MQ objects differ from the Git-defined desired state?
- Which attributes would change?
- Would the proposed pipeline execution modify the queue manager?
- Is there configuration drift between Git and the live environment?
No changes must be made in check mode. The resulting diff should be structured, meaningful, and suitable for review in CI/CD pipelines.
3. Business Value & Strategic Customer Relevance
Why this is a strategic win for IBM?
Declarative automation and Infrastructure as Code are standard industry expectations. Providing an official Ansible Collection is a win-win: It strengthens the synergy between IBM and Red Hat, reduces the barrier to entry for cloud-native projects, and ensures IBM MQ remains the undisputed platform of choice for modern, secure enterprise environments.
Customers increasingly operate their infrastructure according to GitOps, Zero-Touch, and Zero-Trust principles. They expect configuration to be declarative, version-controlled, peer-reviewed, policy-controlled, and deployed through automated pipelines. IBM MQ must fit into this operating model without requiring each customer to develop its own automation framework.
Security and compliance are the central driver
For regulated enterprises, the required operating model is a clear and auditable chain: Pull Request → Peer Review → Approval → Automated Pipeline Execution → Verified Queue Manager State. This model provides evidence of who requested a change, who approved it, what was deployed, when it was deployed, and what state resulted on the queue manager. An official Ansible Collection would enable customers to reduce or eliminate:
- Interactive administrator access to MQ hosts.
- Uncontrolled SSH sessions and direct production changes.
- Locally stored scripts and undocumented operational procedures.
- Shared administrative credentials.
- Inconsistent security configuration across environments.
- Audit gaps caused by manual changes.
CHLAUTH and OAM authorization management are particularly important. Security controls should be managed as reviewed, version-controlled policy rather than as manually executed `setmqaut` commands.
Customers should not have to build this themselves
IBM MQ customers should not be required to spend time and money developing their own Python bindings, PCF abstractions, MQSC parsing logic, idempotency handling, and CI/CD integrations. Every customer that builds this independently incurs unnecessary cost for:
- Development and testing of custom automation.
- Ongoing maintenance across IBM MQ releases.
- Platform-specific behavior and compatibility validation.
- Security hardening and credential handling.
- Building audit, drift-detection, and approval processes around unsupported scripts.
An IBM-supported collection reduces customer administration cost, accelerates delivery, and makes MQ easier to operate consistently across z/OS, Linux, ... estates.
Why does this not already exist?
Declarative automation and Infrastructure as Code are established expectations, not emerging concepts. Enterprise customers have used Ansible, Git, CI/CD, and policy-driven automation for years. IBM MQ should offer an equally mature and supported automation experience for its own administrative object model. If IBM MQ does not provide this capability, customers will either continue to carry the cost and risk of custom automation or evaluate platforms that integrate more naturally into their cloud-native and GitOps ecosystems. An official Ansible Collection would demonstrate that IBM MQ is not only a reliable messaging product, but also a platform that can be operated securely and efficiently in contemporary enterprise environments.
4. Acceptance Criteria
-
Official IBM support
IBM provides and maintains an official `ibm.ibm_mq` Ansible Collection, published on Red Hat Automation Hub and Ansible Galaxy, with support for IBM MQ 9.3 LTS, 9.4, and future supported releases.
-
Idempotent desired-state management
Modules support `state: present` and `state: absent`; re-running an unchanged playbook produces `changed: false`, makes no MQ changes, and does not fail because an object already exists.
-
Complete security and governance support
The collection supports declarative management of CHLAUTH records and OAM authorization records for users and groups, in addition to core MQ object types.
-
GitOps-ready validation
Supported modules implement `--check --diff`, perform no changes in check mode, and provide a clear structured view of planned changes and detected configuration drift.
-
Zero-Touch remote administration
The collection supports secure remote administration through MQ Client/PCF and/or IBM MQ Administrative REST APIs, enabling centrally controlled changes without SSH or direct interactive access to production MQ hosts.
Providing the same for MQ IPT would be warmly welcomed.