I've removed all the parts I generally agree with and have no further
comments. Within this mail I've proposed my alternative solution to
most of defined problems (as I understand them).
> Debops in Debian will mean sticking with Debian release cycle.
> 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
The upstream version doesn't need to. But it's kind of an opportunity to
stabilize DebOps. As I understand it:
- You release some tagged upstream version (say 1.4.0) when most of the things works.
In general it should work with the current... Debian Testing.
- it gets included/updated in the testing Debian
- Testing Debian goes to "freeze" state - and from this moment onwards
you won't be able to change the debops within Debian except for fixing
bugs - so you have a stable branch 1.4, and can publish new 1.4.1, but
1.5 won't get into Debian stable at all.
- Upstream can be changed, released etc - it's not bound by the Debian
cycle, but won't get into Debian until new Debian Stable release -
hence you get a stable release - which has benefits.
recent improvements to Postfix support). Would you want to stick to
roles and playbooks that are included in Debian Buster, or would you rather
use the more recent upstream version?
If my stable debian-reviewed debops still manages correctly my
debian-reviewed stable nginx version - I'm fine with it. Only when I
need some function that is not there I'll be chasing newer versions.
Also - newer upstream version may, or may not work with frozen Debian
nginx version (well - it should. But I'm not so certain about webapps
Down the line I think that there might be major DebOps releases that
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.
Yeah, that exactly that. At least if DebOps is going to "stabilize".
> (... multiple snips ...)
> It's not that important how the code is stored
> - 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.
Some of the described burden is lifted by my idea described below
without a merge. Maintainer would be able to stick to the single repo.
Multiple "stable" versions could be maintained and separate flavors
(snip my own answer as it better described lower)
> Debian often packages stuff using some basic packages and then - modules.
> Checkout puppet-module-* packages for instance - very similar problem and
> already in the tree. Still I'd consider keeping "core" playbooks
> 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.
And I believe it's correct as far as the playbooks don't "age" too much
during Debian release cycle. So - limit dependencies on external
packages/versions if there are any for core playbooks.
> No idea why there can't be a tool to create a release
tarball out of current
> 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.
I'm beginning to understand and feel you problem a bit better. Let me
offer you a more detailed example of how this can work with split repos
and Debian - and a path for stabilizing DebOps (which might not be what
you want anyway, but stick with me for a minute).
Let's forget about tarballs for a second. From the Debian project
perspective "upstream" is whatever you decide to publish. Most of the
time they are still working with the tarballs but what they really want
- a single source of truth
- a version
(relevant afaik: https://wiki.debian.org/PackagingWithGit
If you manage to:
- Provide a single main versioning for the DebOps project (separate
from role/tools versioning). Connected to the single git repo.
- Store a verified info in the main repo about all the required parts -
e.g. a yaml file with list of repositories, and the last verified SHA-1
- Sign this yaml file with hashes - instead of signing separate repos.
- During debops-update VERIFY the file before cloning repos. Clone to
the specified SHA1 only. (This is a security improvement over current
approach I believe)
- Allow people to use some branch instead of SHA1 on request. And add
additional repos to the list so that debops automatically pulls them.
- And finally: Provide a build script inside the main repo which:
- pulls verified repos up to the verified state,
- builds the docs,
- creates a tarball with version in it's name which is
(a given state of
main repo will always produce THE SAME tarball - even if some
branches if other repos change).
So I got back to the tarballs. Tarballs can have a version control
(kind of) but it requires you to periodically build the project (from
validated by you sources) and then sign the resulting tarball. The
connection from the repo and it's SHA1 to the tarball is direct and
I believe this:
- Does solve Debian problem because they can either use your last
produced tarball (github independent) or use your single GIT repo
which has a "compilation" process which calls github in the meantime.
- Shifts your signing issue from signing repos to maintaining a signed
list of commits. So no easy solution. Procedure:
* Maintainers handle their repos themselves. You don't even need access.
* When they believe they are "ok" - they create a PR incrementing the hash in
(so you observe the PR only on one repo)
* You review the PR by checking diff between versions and dropping or
accepting AND SIGNING the change.
- Validates the code better. In my current default debops setup I have
23 NOT SIGNED repositories at all - and I run their code.
for i in $(ls); do pushd $i > /dev/null; git tag --verify $(git describe --abbrev=0
--tags 2>&1) 2>&1 | grep 'Good signature' > /dev/null || echo $i
error ; popd >/dev/null; done
- Allows you to fix previous stable versions:
- checkout the role at commit from which Debian version was created
- fix the bug and tag the fixing commit.
- checkout the main repo at release-commit and:
* increment the fixed role hash,
* sign, increment main version bugfix
- Reproductibly-build the tarball with with only required changes and
update Debian package.
- In semantic versioning:
* You keep the major number if major numbers of all roles didn't change
(no incompatible API changes) - otherwise increment major, zero minor.
* You increment the bugfix version if the update fixes bugs without
* You increment the minor version otherwise (function change, not
bugfix, but API stable).
Instead of the file signing you can probalby sign repo and use
submodules - but that's less explicit, more opaque and doesn't survive
creating a tarball.
So it seems that SHA1 cannot be reliably used to ensure that parent
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.
And there's even now a hole if I understood the process correctly.
debops-update doesn't validate your signatures at all - so attack on gh
repo might alter code running as an administrator if I'm not mistaken.
> (.. snips of things I'm unsure how to answer ..)
With a monorepo layout, everyone has access to their own fork of the
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:
With a described central main "debops" with list of SHA1 this is
possible too. There can be testing/stable branch - pulling different
versions of roles (and different sets of roles) - and the same there
can be more than one single repo. You would be able to create your own
mix of roles, validate as you see fit and sign.
Debops update would accept the file as long as the key would be trusted.
). Since for Ansible
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.
Two-way synchronization can go awry, but would be possible.
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.
Ok, so both approaches would require writting some additional code. ;)
The difference between the current and the new model is that instead
hundreds of source repositories combined into "one" virtual repository we have
one source repository split into multiple ones. Much easier to handle by
That's a bit what I was going at too. This human-project-lead - would
have to consider only one repo and PR to only one repo (except for
occasional git diff to verify if role maintainer is not including a
> (.. snip snip ..)
> Not tying yourself tightly to github is certainly nice, but having multiple
> 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.
True. But can be updated to clone from gitlab by repo name and with
possibility of "freezing" debops version as a verified tarball the
dependency on GH is less of a problem.
Tomasz bla Fortuna
pgp: C009FC9BD59B22FE @ pgp.mit.edu