[suggestion] Redesign Role Naming Scheme

[acch]

Roles are currently structured like this:

roles/
├── callhome/
│   ├── cluster
│   ├── node
│   ├── postcheck
│   └── precheck
├── core/
│   ├── cluster
│   ├── common
│   ├── node
│   ├── postcheck
│   └── precheck
├── gui/
│   ├── cluster
│   ├── node
│   ├── postcheck
│   └── precheck
└── zimon/
    ├── cluster
    ├── node
    ├── postcheck
    └── precheck

There are a few (potential) issues with this naming scheme - one being documented in #189, another one being (in-)compatibility with Ansible Galaxy. I've tried to document further aspects in a separate document.

I'd suggest the following role name scheme to address these issues:

[namespace].[product]_[component]_[action]

Hence, I'd suggest the following directory structure:

roles/
├── scale_callhome_configure
├── scale_callhome_install
├── scale_callhome_prepare
├── scale_callhome_verify
├── scale_core_common
├── scale_core_configure
├── scale_core_install
├── scale_core_prepare
├── scale_core_verify
├── scale_gui_configure
├── scale_gui_install
├── scale_gui_prepare
├── scale_gui_verify
├── scale_zimon_configure
├── scale_zimon_install
├── scale_zimon_prepare
└── scale_zimon_verify

All details can be found in this document. I'm opening this ticket to ask for feedback: does this make any sense? Am I missing something?

Thanks for your time in advance!

[benformosa]

Hi Achim, Has there been any progress on this task at all? Converting this to a collection would be very useful for making use of this repo, particularly so I can easily consume it as a dependency of my playbooks. Thanks so much, Ben

[acch]

Hi @benformosa,

I do have to apologize for not getting back to you on this. In fact, this item slipped from our radar for quite a while... but we've now come back to this and understand that it's important to many users. Thanks for your patience!

I've just created #570 which, once merged, should enable consuming this project as a collection. There are some limitiations with this, still, and we'll need to make some breaking changes to address these. Hence, there will be a new branch for the breaking changes soon, which would then be phase 2 of the changes to fully enable Ansible collections support...

If you like to test then changes already you could give https://github.com/acch/ibm-spectrum-scale-install-infra/tree/dev a try.

What do you think? Your feedback is very welcome!

Thanks and regards!

Achim

[acch]

FYI: I'll start working on phase 2 now: https://github.com/acch/ibm-spectrum-scale-install-infra/tree/nextgen

Stay tuned! ;-)

[acch]

The name changes are now merged into nextgen branch. We'll need a few more (minor) changes and then we can publish the code as a collection on Galaxy. I'll keep this issue updated.

[benformosa]

Is this work now in the main branch? Is there still a plan to release the collection on Galaxy?

[acch]

Hi @benformosa - thanks for your patience! Yes, all name changes are in the main branch by now. You can consume this project as a collection, I do it all the time.

@rajan-mis Are we ready to make main branch default?

You can use the ansible-galaxy CLI client to download and install the collection from github.com directly like so:

# requirements.yml
---
collections:
  - name: https://github.com/IBM/ibm-spectrum-scale-install-infra.git
    type: git
    version: main

Would you prefer fetching the code from galaxy.ansible.com as opposed to github.com? And if so, can you help us better understand the benefits of consuming the code from Galaxy instead of GitHub?

Thanks and regards!

Achim

[benformosa]

Thanks for the info.

My preference would be to consume content from Ansible Galaxy. We use Ansible Private Automation Hub as a way to bring Ansible Content into our network, particularly for use with Ansible Automation Platform.

Our organisation restricts Internet access, and Private Automation Hub provides a way to control which Content is synced with fine grained control.

Private Automation Hub only supports syncing from Ansible Galaxy, Red Hat Automation Hub or compatible repos. However, I've raised a RFE to add that functionality: Red Hat KB: What is the process to sync and upload collections from a Git repository to a Private Automation Hub?