nordic-institute/X-Road

As an Ansible user I would like the roles to be in separate repostiories as done usually for Ansible Roles

tuudik opened this issue · 3 comments

tuudik commented

I suggest to have the playbook located in the same place, but roles as separate repositories and versioned.
Ansible Roles would be then specified in Ansible requirements.yml and shall be downloaded using Ansible Galaxy

raits commented

Hello @tuudik!

Thank you for the suggestion. Could you please elaborate a bit more on why you feel this change should be introduced and what benefits it would bring?

tuudik commented

Sure, so currently if I want to use roles, I need to download the whole repo.
Instead I would like to describe the neccessary roles in my playbook requirements.yml:

---
- src: https://github.com/nordic-institute/ansible.xroad-base.git
  version: 1.3.8
  name: niis.xroad-base
... etc

Then when for downloading the roles I would issue command ansible-galaxy install -r requirements.yml.

This would drop the requirement to download the whole repo for roles.
Also the roles should be versioned, so in case there are changes, they wont break the playbook.
User can switch to new version if he/she has configured neccessary variable that have changed in new version.
This would be the proper way to distribute Ansible roles.

Also it would be more attractive to contribute to the Ansible roles. They shouldn't be taken just for testing purposes but as possible everyday tools.
Since the security server has API, then it would be possible also to implement the whole security server management through Ansible via available APIs. This would introduce IaC aspect.

  • 👍1
raits commented

Hello @tuudik,

Thank you for your reasoning. Since this is a departure from what we use Ansible for, we took some time to also discuss the change internally with the development team. All in all, we see that it would require some extra work from us and a bit of additional attention to how we handle, use and version the Ansible scripts in our environments.

Due to this, we will take the proposal to the next Technical Committee meeting scheduled for the 14th of November to see if it is something our members would like us to support. I will post an update once we have a decision from there.

I will also convert this proposal to a discussion.