12:12 a.m.
On Aug 14, hvjunk wrote:
The whole of the debops playbooks and roles, are quite
inter-dependent, so
it’ll make sense to have them in a single repository.
The question perhaps goes with the debops scripts/wrappers, how much they
are depending on the playbooks/roles to be a separate repository?
In the Ansible world, the “normal” set of roles, are quite autonomous, and
those are the ones in Ansible's Galaxy.
The Debops roles, are too integrated and connected (in my opinion) to truly
be autonomous Ansible Galaxy roles, just look at the ferm role “configured"
from the postgresql/etc. roles to define the port usages.
At least, those are my humble opinions ;)
Thanks for the reply!
Quite contrary, I would say that most of the DebOps roles that use current
standards are designed to be used independently. What joins them together is
the playbooks in the 'debops-playbooks' repository. Consider for example the
PostgreSQL use case you mentioned - if you use the provided example playbook
in the role directory, then yes, it uses 'debops.ferm' to configure the
firewall, since that is used by DebOps playbooks. But, you could write your
own Ansible playbook that includes the 'debops.postgresql_server' and/or
'debops.postgresql' roles and completely skips 'debops.ferm' because for
some
reason you prefer 'ufw' or 'firewalld', and you have PG ports handled
already.
This should not affect the PostgreSQL DebOps roles in any way, since they
don't care about the firewall, instead relying on the 'debops.ferm' role via
dependent variables to configure it.
This is the case for most of the current roles available on
https://galaxy.ansible.com/debops/ webpage. This works because in DebOps roles
don't define their dependencies in the 'meta/main.yml' files of the role, but
on the playbook level. Without 'debops-playbooks' you have just a bunch of
Ansible roles for different applications and services, 'debops-playbooks'
actually defines in what order they are used, and how they relate to each
other.
As for most of the other code that is not related to Ansible directly - the
test suite can be closely tied to the roles, documentation as well. That
leaves the wrapper scripts which could be put in their own subdirectory in the
main repository. After that, the whole shindig could generate for example .deb
packages with existing playbooks, roles, scripts and documentation which can
then be properly tracked by APT. Or, roles and playbooks could be installed
via 'make install' locally. The installation/update procedure would definitely
need to be changed, but we can work that out.
I think that a good benefit with going with just one git repository is that it
decouples the project from any git hosting platform - DebOps repository could
be mirrored on GitHub, BitBucket, a GitLab instance, etc. It would not matter
from where you got it, as long as the GPG signatures are signed by the keys
you trust. At the moment, project is tied to GitHub since the install/update
script looks there for the git repositories, changing that might be benefical.
This leaves us with issue/pull request handling. I'm already thinking about
creating a set of steps that would define how a GitLab + GitLab Runner
+ Docker environment can be created to test the roles using Docker, that way
anybody can test their code before publishing it to upstream. And I'm open to
using the mailing list for the patches/issue tracking, which can allow
contributors that don't want to mess with GitHub.
Cheers,
Maciej