Question regarding the structure of the code (Role/Collection)

[robsonsnt]

Hi,
First of all, I would like to thank you for making this code available to the community.
I would like to ask a question regarding the structure of the code. Have you considered making it available as a collection or a single role to make it possible to install with ansible-galaxy command, for example?
Is there any specific reason to work in the current form?
I am just trying to understand, thank you in advance!

[vitabaks]

Hi @robsonsnt

thank you for your feedback

This project is published on the galaxy and you can install it

Example:

ansible-galaxy install vitabaks.postgresql_cluster,1.10.0

[SamuelMolling]

I can try to help with that.

[vitabaks]

Thank you for responding.

The fact is that I still do not quite understand why the current structure with multiple roles may not be convenient. Perhaps I need to learn more about collections, this is a fairly new term in ansible.

[ThomasSanson]

Hi @vitabaks,

I believe that migrating to the "collection" format in Ansible presents several advantages for the PostgreSQL High-Availability Cluster project. Here are some of the main advantages:

1. Better organization and modularity: Collections allow you to group multiple Ansible roles, plugins, and other components into a single entity. This makes it easier to manage and maintain the project.

2. Reuse and sharing: Collections can be easily shared and reused within the Ansible community, which helps increase the visibility and adoption of the project.

3. Dependency management: With collections, it's easier to manage dependencies between different components of the project, which simplifies installation and updates.

4. Better integration with Ansible Galaxy: Collections are designed to work closely with Ansible Galaxy, which allows for better integration with the platform and simplifies the installation process for users.

An example of a project that has made this transformation is the Confluent Platform Ansible project: https://github.com/confluentinc/cp-ansible. You can see how they have organized their roles, plugins, and other components into a single collection, which greatly facilitates the management and use of the project.

I understand that the concept of collections may be new to some Ansible users, and it's completely normal to wonder why to change the current project structure.

Although the current structure based on multiple roles works, collections offer a more structured and modular organization. Collections help to group and manage Ansible roles, plugins, and other components into a single entity.

Using collections makes it easier to share and reuse the project within the Ansible community. Additionally, collections offer better integration with Ansible Galaxy, which simplifies installation and updates for users.

It's true that migrating to collections may require some learning and adaptation time, but it presents long-term advantages for the management and maintenance of the project.

I encourage you to learn more about collections and to consider this migration to improve the user experience and maintainability of the PostgreSQL High-Availability Cluster project.

I hope this gives you a better idea of the advantages of migrating to the "collection" format for the PostgreSQL High-Availability Cluster project. Thank you for considering this request.

Best regards,
ThomasSanson

[ThomasSanson]

@vitabaks,

I would like to add some additional points to highlight the benefits of transitioning to the Ansible collection format for the PostgreSQL High-Availability Cluster project:

• Transitioning to a collection will allow this project to be fully referenced under Ansible Galaxy. This will make the project more discoverable, and make installation and updates easier for users.
• Users will no longer need to clone or modify the repository, as they can directly use the playbooks and roles from the collection. This simplifies and accelerates the integration of the project into existing environments.
• Transitioning to the collection format can make it easier for enterprise users to contribute. Enterprises are often more willing to allocate official work time to contribute to projects structured as collections.
• Migrating to collections also facilitates the introduction of better testing for the playbook. This will enable the inclusion of installation, recovery, and testing playbooks.
• I encourage you to look at the Confluent Platform (Kafka) project, which has also adopted the collection format and why they made this choice. Their experience can serve as an example for the migration of this project.

I am aware that transitioning to the collection format requires a lot of work, but I am ready to take on this task to ease the workload on your end and ensure a smooth transition.

Best regards,
ThomasSanson

[vitabaks]

I am aware that transitioning to the collection format requires a lot of work, but I am ready to take on this task to ease the workload on your end and ensure a smooth transition.

Thanks @ThomasSanson for the detailed description! And for the fact that you want to contribute to the project.

For me, the main goal has always been to simplify the use of this automation as much as possible for the user, even for someone who is not familiar with ansible at all. That's why I described a detailed README and all the steps for implementing a cluster from scratch.

I think you see more advantages in using the collections format than I do because (apparently) that you understand this better. Let's try to do it.

But the main goal - everything should be as simple and clear as possible for users.