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

[pat-s]

https://galaxy.ansible.com/ui/standalone/roles/vitabaks/postgresql_cluster/ is out of date and in general it would be great to have a collection which contains all roles in https://github.com/vitabaks/autobase/tree/master/automation. This would lean more towards a standard ansible flow. Checking out a git repo and calling included playbooks that change over time is quite uncommon in the ansible world (NB: I am saying this managing multiple Ansible Collections on Galaxy).

Currently, playbooks are large and more like a role itself. The best structure would likely be to migrate the playbooks (like config_pgcluster.yml) to roles. After installation the collection then, users could call a role from the collection with variables defined in group_vars or host_vars. This would be a lot more transparent. Example:

- name: Postgres
  hosts: all
  become: true
  gather_facts: true

  roles:
    - role: autobase.deploy_pgcluster
    - role: autobase.configure_pgcluster
    [...]

In addition, this allow defining autobase as a proper dependency in requirements.yml and allow for automated versioning and updates of dependency versioning tools.

[vitabaks]

I understand your point. Indeed, the postgresql_cluster on Galaxy is no longer updated because it has evolved into Autobase, which we now position as a DBaaS solution with UI-based management.

I see the value in aligning more closely with the standard Ansible flow, but I’m not sure how much this would contribute to the project’s growth or adoption. Would it lead to wider adoption and increased sales?

If this is something you find important, I encourage you to create a feature request, and we’ll evaluate it. However, I can’t promise a high priority for this at the moment, as there are other critical features in development. That being said, if a sponsor is willing to support this effort, we would be happy to consider it sooner.

[pat-s]

I see the value in aligning more closely with the standard Ansible flow, but I’m not sure how much this would contribute to the project’s growth or adoption. Would it lead to wider adoption and increased sales?

If autobase would be become more easy and straightforward to use (which includes simplified embedding into existing Ansible structures), I would expect this, yes.

If this is something you find important, I encourage you to create a feature request, and we’ll evaluate it. However, I can’t promise a high priority for this at the moment, as there are other critical features in development. That being said, if a sponsor is willing to support this effort, we would be happy to consider it sooner.

I guess the overarching question is whether this is a feature or actually a bug, i.e. whether it should have been like this from the start (in an ideal scenario). (Also, subconsciously, the "please donate then we do work" banner is being placed a bit too often in some discussions I've visited here recently).

Using Ansible directly is surely on the expert side and not targeted towards users preferring the UI unless it provides substantial benefits. Maybe autobase needs to make a decision where it wants to go or what it wants to be? (also in terms of open/closed support)
If autobase should be usable directly through Ansible in the longterm as a "goodie" alongside users preferring the UI (and possibly more often requesting help), this would be great. Eventually, these users will also start donating then.

Take me as an example user/client: I am used to work with Ansible and do not need a/the UI. What I need is a thorough and robust way to configure and maintain a (HA)-DB deployment(s). I am willing to donate/pay for it if there is a solid and professional way to do so. Right now I am playing around with autobase and I am unsure if the current approach (deployment-wise) is a good one which I can/want to go with longterm.

Aside from this, I also see advantages for a clear collection/role structure for the project itself. In the end, Ansible is the base and it also gets applied somehow in the background. Doing so by following best practices should also simplify the internal use.

I don't know your Ansible skills. Yet, given you opted for it as the core tool of this project, they should be quite solid. Hence, I hope you understand my proposal (it is only meant to be positive and helpful). In case you need help with a potential restructuring, I am also happy to help.

[vitabaks]

Feel free to submit a PR if you believe it will improve the project without introducing additional inconvenience for long-time users who have been using the current version for years.

Additionally, any changes should not disrupt the existing Console API logic, which executes playbooks rather than roles.

[pat-s]

It will surely be a breaking change in terms of usage and versioning. The important bit though is that you must be convinced about the change, otherwise it doesn't have a base to be operated on in the future.
Ideally the change would be limited to calling a role instead of a playbook and placing the vars differently.

In addition, I would suggest to use a prefix for roles which are user facing to differentiate them from the ones which are internal (if they should be kept as roles like now). (Ideally, there would only be user-facing roles but achieving this would be an even bigger change.)

Additionally, any changes should not disrupt the existing Console API logic, which executes playbooks rather than roles.

It can still call a playbook but the playbook itself then simply needs to execute the roles instead of the tasks directly.

[vitabaks]

While we use Ansible as one of the components in our solution, Autobase is more than just an Ansible role or collection—it is a DBaaS solution. As such, we are not strictly bound by standard Ansible structures, though we follow best practices where they align with our goals.

Our primary focus is on delivering robust database automation and a seamless user experience, which sometimes requires deviations from conventional Ansible patterns.