[debops] New GitHub organization, debops-contrib

Mariano Barcia mariano.barcia at gmail.com
Mon Oct 26 12:29:31 CET 2015


Hello Maciej,

Nice to hear about this.

As a user who may have a few roles to contribute, I'd like to see what
makes a DebOps role different than any other ansible role, and how should a
contrib role integrate with DebOps. For example,

   - What is available
   ​ in DebOps​
   , in addition to Ansible?
   - Dependencies
   ​ to take into account​
   - Best practices (syntax guidelines, use of register, bool, etc.)
   - "Bad" practices
   - Local facts
   ​ and debops-core involvement
   - How the debops​ scripts would affect my role
   - Documentation guidelines
   - ​Automated tests guidelines


Other remarks:
Isn't this the _official_ contrib initiative? IMO, it would be Unofficial
if it weren't you the maintainer/approver.

My 2 cents, thank you
--m



On Mon, Oct 26, 2015 at 11:34 AM, Maciej Delmanowski <drybjed at drybjed.net>
wrote:

> Hello everybody,
>
> 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
> enforced.
>
> 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
> production?
>
> 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 far.
>
> So, any other perspectives on this?
>
> Cheers,
> Maciej
>
>
> 
>
>




More information about the debops-users mailing list