search

lefilament / ansible

Ansible playbook
GNU Affero General Public License v3.0
5 stars 4 forks source link

Usage of requirements.yml in place of submodules #2

Closed nqb closed 3 years ago

nqb commented 3 years ago

Hello,

I suggest to use a requirements.yml + an ansible.cfg at root of repository to avoid usage of git submodules in this repository.

Example:

requirements.yml:

roles:
  - name: docker_server
    src: https://github.com/lefilament/ansible_role_docker_server
    version: master

ansible.cfg:

# Installs **and** lookup collections into [current dir]/ansible_collections/namespace/collection_name
collections_paths = ./

# Installs **and** lookup roles into [current dir]/roles/namespace.rolename
roles_path = ./roles

Are you in favor of such change or do you prefer to keep things as-is ? If yes, I will open a PR.

NOTES:

remi-filament commented 3 years ago

Thank you for this proposal @nqb ,

I have not enough followed the improvements on Ansible lately, my initial idea with having critical roles outside main repo was to allow anyone to clone/fork/use only that role for its needs without the need to get the full repo. I then used submodules for inclusion.

I like your proposai. On requirements.yml can you specify a specific commit on version: ? Otherwise we may lose this granularity offered by submodules (though I always load thé master, so that should not ne problematic).

Feel free to propose a PR ! Best Regards

nqb commented 3 years ago

On requirements.yml can you specify a specific commit on version: ?

Yes: https://docs.ansible.com/ansible/latest/galaxy/user_guide.html#installing-multiple-roles-from-a-file (see examples) But as I mentioned, we need a meta/main.yml in each role in order to use ansible-galaxy like described previously.

Do you want to create such a file for each of your linked role ?

You can find a minimal example I wrote here: https://github.com/inverse-inc/ansible-packetfence/blob/a033dab98c15705b72a82c028e65a1e2ee8eeed3/packetfence/roles/packetfence_install/meta/main.yml

nqb commented 3 years ago

After thinking a bit about my proposal, I think the best solution is to have everything in a simple repo (monorepo).

This has several advantages:

If you use several roles of this repo to set up an Odoo server and want to contribute, you have to fork several roles and create a PR in each repository.

Let me know which approach do you prefer.

remi-filament commented 3 years ago

From a code perspective I guess what you propose is the same as what we have today. I understand your point about contribution (where to create issue / pull requests), I will have to think more about this one, since for me having all roles in the same repo would limit the reuse of single role by other contributors (for instance people already having ansible will to only add/fork one of the docker_xxx role)

remi-filament commented 3 years ago

Hi @nqb I finally migrated all roles outside the main repo, since some of these should still be working but I am not using anymore, so I prefer to let people know which ones are still maintained. Also I wanted to move everything back to our GitLab server, but one can only connect to Ansible Galaxy using GitHub creds so I made a copy of each role on GitHub as well (the main repo being on out GitLab server). Since for now our GitLab server is not allowing external people to create account, people could still use GitHub for PR/Issues this way.

nqb commented 3 years ago

Hello @remi-filament,

Thanks for your message.

  1. Could you link commits/PR to this issue ?
  2. If you used a collection, you don't need to host your code on GitHub to import it on Galaxy. Also, requirements.yml allow you to install roles directly from a Git source tree based on a tag or a branch.
  3. I think it will be a pain for you to accept external contribution opened on GitHub. It's not possible to have limited access to some GitLab repositories on your GitLab server ?
remi-filament commented 3 years ago

Please find below the corresponding commits :

  1. Ansible requirements.yml and remove of roles : f5d6736a2d3678cc5a7d9b89e11c3a271f8d3c5b and fbfbc321cf218b754580c7ffa27f9f7272482108
  2. various roles being listed in requirements.yml :
    1. docker_odoo : https://github.com/lefilament/ansible_role_odoo_docker/commit/bff8f325606fc145f4b6026ba7c07c8d17e834b7
    2. docker_server : https://github.com/lefilament/ansible_role_docker_server/commit/09a33ba5779bee7be10587ca7a2437e7c397dbae
    3. etc.

I pushed roles independently on Galaxy, not collection, which does not make much sense to me (and I did not manage to import directory with my playbook in Ansible Galaxy directly...) Next step would be to not import roles from Ansible Galaxy but configure GitLab CI to push them automatically to Ansible Galaxy, and to allow people to create either anonymous issues on our Gitlab or to allow creation of account (but I do not think that people will create a dedicated account only to raise an issue or propose a PR, thus not sure this is the best way). Also you are the only who contributed to my roles so far, so I do not expect tons of contributions :smile: so I guess I could still manage from 2 different sources !

Eventually, you asked me some time ago if Odoo 14 was working, and we did not use it at that time, but we now have deployed a few customers with v14 now, so yes it is working !

nqb commented 3 years ago

I pushed roles independently on Galaxy, not collection, which does not make much sense to me (and I did not manage to import directory with my playbook in Ansible Galaxy directly...)

I will find it helpful because currently there is no release for each role. So you have to track each role by commit or use the latest revision.

Do you plan to manage releases in the future ?

remi-filament commented 3 years ago

Yes, I will look into it, good idea ! Best Regards,

nqb commented 3 years ago

@remi-filament,

Could you create me an account on your GitLab repository (sources.lefilament.com) ? IMHO, it makes more sense to open issues and create MR directly on sources.lefilament.com.

EDIT: you can find my email address in commit history.