Hi Ankur,

Thank you for sharing your project and code! It is great to see the community actively driving the modernization of IBM MQ administration towards GitOps and Infrastructure as Code (IaC).

In our enterprise environment, we are pursuing a very similar strategic approach. As an enterprise user focusing on long-term maintainability and standardization, we closely follow the development of the official IBM Ansible Collections and align our IaC roadmap with vendor-supported solutions.

To address your specific questions and share some thoughts on your technical approach:

1. Viability & Essential Objects (Questions 1 & 2):
Representing MQ configurations declaratively in YAML is definitely the right way forward. For a true "Objects as Code" model in an enterprise environment, covering the full spectrum of object types is essential. Beyond local queues, this must include remote/alias queues, all channel types (SDR, RCVR, SVRCONN, etc.), topic definitions, process definitions, and authentication information objects, etc.

2. Validation and Idempotency (Question 3):
Strict idempotency is non-negotiable for production environments. One of the main challenges with MQ is platform diversity. A robust IaC approach must validate and execute consistently across various OS platforms (Linux/AIX, Windows, but also z/OS and MQ Appliances). This is also where we, as enterprise customers, look forward to robust, vendor-backed validation mechanisms within the official collections in the future.

3. Technical Food for Thought:
Your current workflow relies on generating and executing MQSC commands (e.g., via `runmqsc` or `CSQUTIL` on z/OS). While this is proven and highly efficient, you might want to consider two alternative interfaces to further enhance platform-agnostic automation:

• PCF (Programmable Command Formats): Using an MQ client with PCF allows for highly precise, programmatic object management directly over the network.
• REST API (MQ Web Administration): Leveraging the administrative REST API is ideal for modern CI/CD pipelines. It integrates beautifully with Ansible (e.g., via the `uri` module) without requiring local MQ administration tools on the executing node.

Thank you again for this valuable initiative. I am excited to see how your project and the official vendor collections will continue to evolve and inspire each other!

Best regards,
Martin

Thank you for taking the time to write your valuable feedback.

Initially, I started this project simply to brush up on my Ansible skills, but it got interesting along the way and I decided to keep developing it further. My main goal has been to keep the approach simple and practical.

That's also why I decided to use MQSC commands. If an MQ administrator comes across the project, they shouldn't need to be an Ansible expert to understand what is happening. The MQSC commands should make the intent and the actual MQ configuration easy to follow.

I'll definitely try to keep this approach as I continue developing the project and make it more scalable and obeservabiltiy and finally move towards Event based automation. 

Hi Ankur,

Thank you for sharing your project and code! It is great to see the community actively driving the modernization of IBM MQ administration towards GitOps and Infrastructure as Code (IaC).

In our enterprise environment, we are pursuing a very similar strategic approach. As an enterprise user focusing on long-term maintainability and standardization, we closely follow the development of the official IBM Ansible Collections and align our IaC roadmap with vendor-supported solutions.

To address your specific questions and share some thoughts on your technical approach:

1. Viability & Essential Objects (Questions 1 & 2):
Representing MQ configurations declaratively in YAML is definitely the right way forward. For a true "Objects as Code" model in an enterprise environment, covering the full spectrum of object types is essential. Beyond local queues, this must include remote/alias queues, all channel types (SDR, RCVR, SVRCONN, etc.), topic definitions, process definitions, and authentication information objects, etc.

2. Validation and Idempotency (Question 3):
Strict idempotency is non-negotiable for production environments. One of the main challenges with MQ is platform diversity. A robust IaC approach must validate and execute consistently across various OS platforms (Linux/AIX, Windows, but also z/OS and MQ Appliances). This is also where we, as enterprise customers, look forward to robust, vendor-backed validation mechanisms within the official collections in the future.

3. Technical Food for Thought:
Your current workflow relies on generating and executing MQSC commands (e.g., via `runmqsc` or `CSQUTIL` on z/OS). While this is proven and highly efficient, you might want to consider two alternative interfaces to further enhance platform-agnostic automation:

• PCF (Programmable Command Formats): Using an MQ client with PCF allows for highly precise, programmatic object management directly over the network.
• REST API (MQ Web Administration): Leveraging the administrative REST API is ideal for modern CI/CD pipelines. It integrates beautifully with Ansible (e.g., via the `uri` module) without requiring local MQ administration tools on the executing node.

Thank you again for this valuable initiative. I am excited to see how your project and the official vendor collections will continue to evolve and inspire each other!

Best regards,
Martin

Hi Ankur,

your forum post got me thinking and finally prompted me to dust off and finalize an idea/request for IBM that I prepared many months ago. I submitted the 'Idea' for an IBM MQ Ansible Collection today and would be very happy to have your support, as well as the support of anyone else who might be interested.

Best regards,
Martin

Thank you for taking the time to write your valuable feedback.

Initially, I started this project simply to brush up on my Ansible skills, but it got interesting along the way and I decided to keep developing it further. My main goal has been to keep the approach simple and practical.

That's also why I decided to use MQSC commands. If an MQ administrator comes across the project, they shouldn't need to be an Ansible expert to understand what is happening. The MQSC commands should make the intent and the actual MQ configuration easy to follow.

I'll definitely try to keep this approach as I continue developing the project and make it more scalable and obeservabiltiy and finally move towards Event based automation. 

Hi Ankur,

Thank you for sharing your project and code! It is great to see the community actively driving the modernization of IBM MQ administration towards GitOps and Infrastructure as Code (IaC).

In our enterprise environment, we are pursuing a very similar strategic approach. As an enterprise user focusing on long-term maintainability and standardization, we closely follow the development of the official IBM Ansible Collections and align our IaC roadmap with vendor-supported solutions.

To address your specific questions and share some thoughts on your technical approach:

1. Viability & Essential Objects (Questions 1 & 2):
Representing MQ configurations declaratively in YAML is definitely the right way forward. For a true "Objects as Code" model in an enterprise environment, covering the full spectrum of object types is essential. Beyond local queues, this must include remote/alias queues, all channel types (SDR, RCVR, SVRCONN, etc.), topic definitions, process definitions, and authentication information objects, etc.

2. Validation and Idempotency (Question 3):
Strict idempotency is non-negotiable for production environments. One of the main challenges with MQ is platform diversity. A robust IaC approach must validate and execute consistently across various OS platforms (Linux/AIX, Windows, but also z/OS and MQ Appliances). This is also where we, as enterprise customers, look forward to robust, vendor-backed validation mechanisms within the official collections in the future.

3. Technical Food for Thought:
Your current workflow relies on generating and executing MQSC commands (e.g., via `runmqsc` or `CSQUTIL` on z/OS). While this is proven and highly efficient, you might want to consider two alternative interfaces to further enhance platform-agnostic automation:

• PCF (Programmable Command Formats): Using an MQ client with PCF allows for highly precise, programmatic object management directly over the network.
• REST API (MQ Web Administration): Leveraging the administrative REST API is ideal for modern CI/CD pipelines. It integrates beautifully with Ansible (e.g., via the `uri` module) without requiring local MQ administration tools on the executing node.

Thank you again for this valuable initiative. I am excited to see how your project and the official vendor collections will continue to evolve and inspire each other!

Best regards,
Martin

Hi Ankur,

your forum post got me thinking and finally prompted me to dust off and finalize an idea/request for IBM that I prepared many months ago. I submitted the 'Idea' for an IBM MQ Ansible Collection today and would be very happy to have your support, as well as the support of anyone else who might be interested.

Best regards,
Martin

Thank you for taking the time to write your valuable feedback.

Initially, I started this project simply to brush up on my Ansible skills, but it got interesting along the way and I decided to keep developing it further. My main goal has been to keep the approach simple and practical.

That's also why I decided to use MQSC commands. If an MQ administrator comes across the project, they shouldn't need to be an Ansible expert to understand what is happening. The MQSC commands should make the intent and the actual MQ configuration easy to follow.

I'll definitely try to keep this approach as I continue developing the project and make it more scalable and obeservabiltiy and finally move towards Event based automation. 

Hi Ankur,

Thank you for sharing your project and code! It is great to see the community actively driving the modernization of IBM MQ administration towards GitOps and Infrastructure as Code (IaC).

In our enterprise environment, we are pursuing a very similar strategic approach. As an enterprise user focusing on long-term maintainability and standardization, we closely follow the development of the official IBM Ansible Collections and align our IaC roadmap with vendor-supported solutions.

To address your specific questions and share some thoughts on your technical approach:

1. Viability & Essential Objects (Questions 1 & 2):
Representing MQ configurations declaratively in YAML is definitely the right way forward. For a true "Objects as Code" model in an enterprise environment, covering the full spectrum of object types is essential. Beyond local queues, this must include remote/alias queues, all channel types (SDR, RCVR, SVRCONN, etc.), topic definitions, process definitions, and authentication information objects, etc.

2. Validation and Idempotency (Question 3):
Strict idempotency is non-negotiable for production environments. One of the main challenges with MQ is platform diversity. A robust IaC approach must validate and execute consistently across various OS platforms (Linux/AIX, Windows, but also z/OS and MQ Appliances). This is also where we, as enterprise customers, look forward to robust, vendor-backed validation mechanisms within the official collections in the future.

3. Technical Food for Thought:
Your current workflow relies on generating and executing MQSC commands (e.g., via `runmqsc` or `CSQUTIL` on z/OS). While this is proven and highly efficient, you might want to consider two alternative interfaces to further enhance platform-agnostic automation:

• PCF (Programmable Command Formats): Using an MQ client with PCF allows for highly precise, programmatic object management directly over the network.
• REST API (MQ Web Administration): Leveraging the administrative REST API is ideal for modern CI/CD pipelines. It integrates beautifully with Ansible (e.g., via the `uri` module) without requiring local MQ administration tools on the executing node.

Thank you again for this valuable initiative. I am excited to see how your project and the official vendor collections will continue to evolve and inspire each other!

Best regards,
Martin