UX: Difference between APB and "Role" in Ansible Galaxy

[JJediny]

As a user...

I found/find myself struggling to understand the best way to format my git repository for an APB service that is also currently being used as an ansible role in production . Is there a way to structure an ansible repository to support both sets of best practices?

Role example from https://docs.ansible.com/ansible/2.5/user_guide/playbooks_reuse_roles.html

site.yml
webservers.yml
fooservers.yml
roles/
   common/
     tasks/
     handlers/
     files/
     templates/
     vars/
     defaults/
     meta/
   webservers/
     tasks/
     defaults/
     meta/

APB example from https://github.com/ansibleplaybookbundle/ansible-playbook-bundle/blob/master/docs/getting_started.md

my-test-apb/
├── apb.yml
├── Dockerfile
├── playbooks
│   ├── deprovision.yml
│   └── provision.yml
└── roles
    ├── deprovision-my-test-apb
    │   └── tasks
    │       └── main.yml
    └── provision-my-test-apb
        └── tasks
            └── main.yml

What is confusing is the sub-directory for roles, it (seems it) does not work with ansible galaxy requirements.yml import. I like the overall idea of having a defined set of 5 actions (provision, deprovision, test, bind, unbind according to the open service broker api spec); but its not clear at all/or/in the least how these two regimes of ansible formated directories co-exist?

Is there a way to make a repo minimally conformant to both? and if not that what are the best suggestions for those trying to migrate current ansible roles into an APB, while still keeping them maintainable in the ansible galaxy default/defacto file directory layout?

[rthallisey]

Hey @JJediny great question. What I would recommend is following a similar pattern that kubevirt did. The apb is in the kubevirt-apb repo and the "production playbooks" are kubevirt-ansible.

This model separates the apb from the ansible-playbook and pulls in the ansible-playbook with a ansible-galaxy install xxxxx, which is essentially a git clone that's done as part of the container build. Once you have the separate apb repo and you're pulling the production playbook into the contianer, now you can create a playbook in the apb repo that is formatted like an apb. That playbook would run an import playbook: production_playbook.yml to call the production role(s) so you can maintain you existing format.

Let me know if that works for you.

[dymurray]

@JJediny I want to add on top of Ryan's comments that we are looking to refactor the APB format so that it better conforms to a Galaxy role. The timeline for this is probably end of May. This will allow you to publish and share APBs on Galaxy as well.

[djzager]

@JJediny just wanted to make you aware that we have updated a few of our APBs to better conform to Galaxy role style.

• Bug 1570603: Make mediawiki-apb (de)provision idempotent mediawiki-apb#31
• Bug 1570603: Make postgresql-apb (de)provision idempotent postgresql-apb#45
• Bug 1570603: Make mariadb-apb (de)provision idempotent mariadb-apb#31
• Bug 1570603: Make mysql-apb (de)provision idempotent mysql-apb#31

The most important part to that change was to update the associated Dockerfile and rpm spec. For example here is the modified Dockerfile for mediawiki and here is the modified RPM spec. Not sure if you need to worry about building RPMs but thought I would share anyway. Hope this helps.