[debops-users] Tips for a new role

Maciej Delmanowski drybjed at drybjed.net
Mon Nov 27 10:00:34 CET 2017

On Nov 26, Stuart Read wrote:
> I'm interested in trying my hand at making a role to install/configure a
> photo-management software ( https://lychee.electerious.com/ if you're
> curious).

Neat application. I briefly looked if there are efforts to package it in
Debian, but there appear to be none. Maybe an opportunity to do so?

> I have a couple of questions:
>  - What is the best role to use as an example of the new debops.php role
>  (and mariadb)? This is a pretty standard PHP/mysql kind of program.

Don't forget the webserver. :-) Integration should be straightforward via the
role dependent variables. For php role, you can look how the 'debops.dokuwiki'
handles the 'debops.php' configuration.

Default variables:


Currently I don't have good PHP-based role that uses MariaDB around (existing
ones need to be updated), but you could look at 'debops.etherpad' which uses
MariaDB as optional dependency.

Default variables:


Remember that the 'debops.mariadb_server' is handled separately and shouldn't
be used as a dependency directly.

>  - How are debops-contrib roles handled in the new monorepo future?

The existing 'debops-contrib' roles in the monorepo will be integrated with
the main playbook at some point, that is renamed, cleaned up, their playbooks
moved to the `ansible/playbooks/` directory, etc. The 'debops-contrib'
organization on GitHub in its current state shouldn't be needed anymore.

I'm considering adding a 'CODEOWNERS' file so that GitHub can automatically
request reviews from people based on files they are interested in:
I have some quailms, since it looks like if you specify a list of people
interested in a particular file(s), this overrides the global list instead of
adding people to it, but maybe if you "watch" a repository you get
a notification about a PR as well? Not sure, I guess we will find out. I'll
check out how other projects use this functionality first.

If you want to contribute a role to the project, just fork the main monorepo
and add your role as usual in the 'ansible/roles/' directory, its
corresponding playbook in 'ansible/playbooks/service/'.

Documentation should go into 'docs/', however that's not finished yet. You can
see that the 'debops.apt' documentation was moved there already but that
caused problems with many missing references to variables from the
'defaults/main.yml' file, so I stopped doing that to first add yaml2rst
support in the Sphinx code. When that's done, all role documentation will go
there and monorepo will be hooked up at https://docs.debops.org/.

These rules should probably go into DebOps Policy documentation, which also
needs to be updated to the new reality. All in good time. :-)

I think that question deserves a more extensive discussion. I would like to
see DebOps in Debian 'main' component of the Debian Archive at some point.
That means that DebOps, at least the main project repository, should conform
to the Debian Free Software Guidelines:

Packages in the 'contrib' component usually depend on non-free software,
either in Debian 'non-free' component or on external software. So how does
that look if DebOps has roles that depend on non-free software? I believe that
the same rules would apply, and that would force the DebOps package to be
included in the 'contrib' component of the Debian Archive, so let's avoid

But, the non-free roles and playbooks could be managed in a separate git
repository. You could install that repository alongsite DebOps monorepo, say
in ~/.local/share/debops/debops-contrib/; all there is is to update the
'debops' scripts to handle multiple playbooks at once and allow configuration
of multiple role/playbook directories where the script points Ansible at.

This would probably call for restructuring of the 'site.yml' playbook, so that
not all roles are executed at once and runs can be faster. When the CLI
supports selecting multiple playbooks to run, some more esoteric roles will
probably be removed from the main playbook.

Of course for this, an entire separate organization on GitHub is unnecessary;
there could be just another repository, say, debops/debops-contrib, with
similar usage patterns as the main repository. Fork it, add your roles to it,
make a pull request.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <https://lists.debops.org/pipermail/debops-users/attachments/20171127/57cdb671/attachment.sig>

More information about the debops-users mailing list