New GitHub organization, debops-contrib
drybjed at drybjed.net
Mon Oct 26 11:34:47 CET 2015
Due to a need to create a place where people can keep Ansible roles and other
things related to DebOps but not directly in the project, I've created the
"debops-contrib" GitHub organization: https://github.com/debops-contrib/.
Access to it is less restrictive than to the "debops" organization, members
can create their own git repositories by themselves. Currently roles available
there are not accessible through Ansible Galaxy, I'll see what can be done
about that. For now, you can clone the roles directly from GitHub and
integrate them pretty easily with the rest of the project.
Roles from 'debops-contrib' might eventually be migrated to official DebOps
organization, so using the 'ansible-*' repository name format is preferable.
For anyone that wants contributor access, please let me know either via GitHub
issues in the 'debops-contrib/debops-contrib' repository, or on the IRC
channel, or through the mailing list.
I think it's also a good opportunity to discuss some aspects of the project,
namely what should be a definition of an official DebOps role, and what comes
with it? For a quick comparsion, Debian project has specific policies about
what can be included in a Debian repository, which can be checked and
Many of the DebOps users use these roles in their production environment,
sometimes on almost all or all of their hosts. I imagine some of you (myself
included) would like to have some kind of assurance that the code you are
using is genuine, there are no hidden holes or exploits included. How many of
you have checked the role and playbook contents before running them in
>From my perspective, I wrote most of the official DebOps roles, I know what is
in there and what will be done on the hosts I manage. As for the roles other
people have contributed so far, I've read them and accepted their code by
signing the git tags included in the repository. If you want, you can trust my
GPG signature on the tags after checking them. I don't think there's currently
any other mechanism included in Ansible to check for role/playbook integrity
So, any other perspectives on this?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 585 bytes
Desc: not available
More information about the debops-users