On Aug 13, Maciej Delmanowski wrote:
The user bla, from the IRC channel, sent me these comments which I'm
responding to on the mailing list:
Debops merge notes
NOTE: I've got not idea how code signing works currently in project.
Getting debops packaged into Debian would be great. And if this requires
some major changes then they may be worth it.
Debops in Debian will mean sticking with Debian release cycle. Roles will
have to work with the Debian release which includes them - freezed at
various versions. Some might stop working fast for example with non-freezed
webapps (e.g. owncloud). Unless they use owncloud from Debian packages
itself? Some roles might not be a good candidates for Debian packaging at
This would probably be better answered by interested Debian Developers,
however I don't think that DebOps itself should strictly follow Debian release
cycle. For example, let's say that Buster provides DebOps packages with
playbooks and roles that work with the nginx version released with Buster.
Then, down the line, DebOps improves its support for nginx (just like with
recent improvements to Postfix support). Would you want to stick to the DebOps
roles and playbooks that are included in Debian Buster, or would you rather
use the more recent upstream version?
The 'debops' scripts that come with the project should "know" and use
packaged DebOps roles and playbooks, which presumably would be somewhere in
/usr/share/debops/, but if the user installs the playbooks and roles from
upstream, ie. from GitHub, then the 'debops' script should gracefully switch
to them. This should be easily doable and it will most likely happen in the
More about Debian compatiblity, we have an existing case where 'ansible'
package in Debian Stretch is incompatible with DebOps due to issues with the
YAML Python support: https://github.com/debops/debops-playbooks/issues/375
Debian Testing already has newer 'ansible' package which should be compatible
with DebOps. Hopefully when new Ansible version is released, it will make it
to Debian Testing before freeze.
Down the line I think that there might be major DebOps releases that stick to
Ansible versions supported by specific Debian release - that's the major
dependency chain of the project. DebOps currently tries to support current
stable Ansible release, and I'm not adding code that relies on Ansible
features that hadn't been released in a stable release yet.
You'd need an option to use Debian debops version with external
This is easily doable and currently possible at the project directory level
with ansible.cfg 'roles_path' parameter. The script that generates ansible.cfg
could be extended to take /usr/share/debops/ into account.
I love Ansible for including quite a huge set of built-in modules. In
puppet world, for most, I'd have to search for external modules on various
stability levels with integration problems. I would love if the debops
worked in a similar way to Ansible - batteries included. Still "worked" !=
This is currently somewhat enforced in DebOps due to the fact that Ansible
playbooks require all roles mentioned in them to be present and available. Due
to ease of use, all playbooks in DebOps are included in 'site.yml', and
because of that all of the DebOps roles need to be installed for the whole
setup to work correctly.
Since DebOps roles are usually focused on specific Debian packages, changing
the project to allow download of selected roles only (when number of roles
will start ot exceed say, 300) could be a solution to the problem of needing
all of the roles together. The 'debops' script would need to be modified to
somehow natively support playbook chaining, you could select what playbooks
are included by default via symlinks in some directory... Of course handling
the order of playbooks becomes a problem and needs to be handled separately
from Ansible... I guess it's an issue we can tackle later down the road.
It's not that important how the code is stored (separate/mono
- but how it's used (and tested). You can certainly test master branches of
all repos together - Travis might not be the best service to do it just.
Using separate repositories becomes a problem when the maintenance is tied to
a human via GPG signing. Let's say you want to introduce changes that affect
multiple DebOps roles. In the current setup (multiple repositories, changes
pushed via GitHub pull requests), each repository needs to be changed
separately via its own pull request, each one signed separately by a human. In
the monorepo, you can combine all of the changes (in separate commits) into
one pull request against one repository. This is a big win for the human.
The roles could still be split into separate repositories sourced from the
monorepo; that version of the code could be signed by a bot with a GPG key
that is signed by the DebOps Developers GPG keys. It's a bit weaker path of
trust, but the code can be easily traced back to the monorepo.
Travis is a separate problem. Right now, DebOps roles are tested in an
automated fashion against single environment, namely Ubuntu Trusty which isn't
even the main targed of the project. Due to Travis restrictions, limited code
paths can be tested as well. With custom GitLab setup, DebOps could be tested
much more throughly and on multiple OS distributions and releases.
Debian often packages stuff using some basic packages and then -
Checkout puppet-module-* packages for instance - very similar problem and
already in the tree. Still I'd consider keeping "core" playbooks together
the basic package.
From what I've seen from two attempts at packaging DebOps for Debian,
packagers prefer merging the Ansible roles together in one package, but that
might be due to the mentioned requirement of Ansible that all roles in
a playbook need to be installed for the playbook to work.
If using separate roles is favored - that might be because it's
include a single role on someones else codebase than to role debops as
a whole (this needs dedication I guess. Fresh start, etc.) Git layout might
help… but I guess it's secondary - and not really all that bad I guess.
On the docs
Assuming the good docs will note a version when something changed/was added:
you can keep the docs build separately from repositories of playbooks in
a single repo - debops-handbook. And rebuild periodically/automatically
(maybe using debops-playbooks repo?). Rebuild would be required after
tagging new version certainly.
That would require a synchronization between changes in the roles/playbooks
repository and documentation repository, which means more pull requests to
handle, which means documentation might diverge over time due to developer
fatigue... Documentation could be exported to a separate repository if needed,
but I think that keeping it with the rest of the project in one git monorepo
as a source is a better approach.
No idea why there can't be a tool to create a release tarball out
state of roles - including/excluding some and sticking to master branch - or
specific tags. Then do the packaging from this release. Treat the tarball as
"upstream" - not the GIT.
There totally can be a tool that exports the code from the monorepo to a set
of tarballs which are then published on some HTTP server. But tarballs cannot
be the "upstream" because they lack proper version control. The
needs to be a proper source git repository.
If keeping separate:
Is it possible to automate adding a new role using existing tools?
debops-init –new-role? Is it really done that often that it creates problem?
Most of the problems (release notes, changelogs) can be solved one way or
another with multiple repos.
Yes, but there's a critical step where all of the commits need to be signed by
a GPG key. To keep it straight, my GPG signing is not automated at all.
I mention this due to this StackExchange answer from 2013 that mentions Linus
Torvalds shunning commit signing in git:
And then, SHA1 got shattered... http://shattered.io/
There's a tread related to this on HackerNews:
So it seems that SHA1 cannot be reliably used to ensure that parent commits
not signed by GPG are genuine. Combine this with the fact that at the moment
DebOps is hosted and downloaded from GitHub. So yeah, I'm signing my commits
and merges, manually. Of course this becomes a bottleneck with number of
repositories, which switch to the monorepo will hopefully solve.
Being able to use external roles from GH, not included in the bundle should
be left as an option - and should be easy. Would also enable merging the
roles partially - role by role.
Use of 'roles_path' in ansible.cfg solves that problem for us, and even lets
you mask roles selectively by using the same role names.
There will be an issue with privileges for multiple maintainers using
repo at some point.
I believe that issues with privileged access to the DebOps repositories are
due to it being hosted in a GitHub organization instead of a single git
repository. Managing access to repositories on GitHub is a bit involved, and
since there are more and more repositories with Ansible roles, this would
With a monorepo layout, everyone has access to their own fork of the DebOps
repository and can create pull requests as they wish against other developers.
Each DebOps Developer can have their own fork of the project and users can
select which Developer they follow (compare that with Linux kernel where
developers have their own git repositories on git.kernel.org
and users can
freely choose which developer they follow:
). Since for Ansible Galaxy there
would probably have to be one "official" set of roles, the debops/debops
repository on GitHub could be shared between DebOps developers and two-way
synchronization merges could be done against their own forks. Then, a set of
scripts could extract the roles from the debops/debops repository
periodically, say on a new tagged release, and publish them on Ansible Galaxy.
That way users that prefer using specific DebOps roles can still do so via
Ansible Galaxy, and users that perefer using the whole DebOps project can use
either the official repository, or one of the forks.
The difference between the current and the new model is that instead of
hundreds of source repositories combined into "one" virtual repository we have
one source repository split into multiple ones. Much easier to handle by
In general - I guess if the role is self-contained and works with
it's worth a separate repo. I've got no idea how many work like that. I've
got only some idea of `core' role currently.
Sure. And since this will be automated, we can as well publish all the
project roles on Galaxy, no need to select which ones are privileged.
I believe the split layout has major advantages too. Maybe not all
should be merged - certainly the "core" set…
My take on what roles should be "core":
The ones which are required by other core roles.
Roles which are required by many non-core roles.
Ones which use only Debian packages and can be easily "frozen" with the
all those executed when host is not yet added into any service groups.
some of the others, but only if they are maintained at the same
This clashes with the current Ansible requirement that all roles in a playbook
need to be available. Maybe in the future, when 'debops' scripts can properly
handle multiple default playbooks at once.
Not tying yourself tightly to github is certainly nice, but having
repos doesn't necessary cause that.
Multiple repositories are harder to handle without some synchronization tool
like debops-update, which is currently tied to GitHub.
Thanks for your comments,