I'm using DebOps to set up a GitLab runner with libvirt and
vagrant-libvirt in order to test applications in a GitLab pipeline.
Exactly the same way DebOps use it to test Ansible roles.
With the default configuration of roles, I'm able to start VMs through
vagrant if I adjust sudo configuration for gitlab-runner user. I don't
want to use sudo and I saw that tests under DebOps don't use it.
I'm not yet very familiar with debops.libvirtd but I'm sure there is
something to tweak in order to use libvirt without sudo privileges.
Thanks for your help.
Jabber/XMPP : nqb(a)azyx.fr
DebOps v1.0.0 is here, let's release the HypnoDrones.
New DebOps release, v1.0.0
You can find the new version of DebOps on:
Galaxy: https://galaxy.ansible.com/debops/debops/ (but see below)
You can upgrade the Python-based installation by running the command:
pip install --upgrade debops
The experimental support for multi-role repositories will be/has been removed
from Ansible Galaxy and Mazer. The Ansible team is instead introducing Ansible
Collections, which use tarballs to distribute Ansible content instead of git
repositories. The Mazer client knows how to use it, but Ansible Galaxy doesn't
yet, therefore new DebOps release will not show up there until June 2019 when
new version of Ansible Galaxy service is released. Until then, you can build
your own tarball with DebOps roles using the 'make collection' command, or
install DebOps via PyPI or directly from the GitHub repository. Installation
instructions can be found here:
The brief Changelog can also be found on the documentation page:
Complete, detailed changelog can be viewed using the 'git log' command.
The DebOps documentation has a separate page which details important changes
from previous release in the Ansible inventory or on the remote hosts which
you might need to perform manually:
The Python packages available on PyPI, as well as the tarballs available on
GitHub are signed with my GPG key. You can get it from the OpenPGP keyserver
network using the command:
gpg --keyserver hkp://pool.sks-keyservers.net \
The v1.0.0 release contains ~370 commits since the last release in February
2019, not counting merges. Here are the usual suspects:
237 Maciej Delmanowski
32 Alin Alexandru
29 Leonardo Bechea
21 Robin Schneider
10 Imre Jonk
8 Jérémy Gardais
5 Thomas Danielsson
4 Hartmut Goebel
4 Reto Gantenbein
3 Rainer 'rei' Schuth
2 Damiano Venturin
2 Serge Victor
1 André Jucovsky Bianchi
1 Dionysis Grigoropoulos
1 Jonathan Struebel
1 Julien Palard
1 Mike Mindel
1 Nicolas Quiniou-Briand
1 Stefan G. Weichinger
1 Tim Freund
Thanks to everyone involved in this release, and I see you in the commits.
Goals reached since previous release
The LDAP support has been completely redesigned from the ground up, both on the
server-side ('debops.slapd' role), and in the new client-side ('debops.ldap'
role). At the moment LDAP can be enabled for basic system services - UNIX
accounts and groups, 'sudo' configuration, SSH public key lookup. There are
still many more DebOps roles which have to be updated to use the new
infrastructure, but that will come in later releases.
Support for Docker Registry comes to DebOps as well, via the
'debops.docker_registry' Ansible role. This role integrates with the
'debops.gitlab' role which you can use to manage the Registry contents.
The rest of the goals outlined in the previous release were not met due to
focus on other things. But there are many new features and bugfixes present, I
suggest you check the Changelog for details.
The first stable release of DebOps is here
I decided to make the first stable release of DebOps early due to the fact that
the project is used more and more in production environments, where large
changes of the various roles might not be possible. A few times users of the
v0.8.1 release found bugs in some roles that were fixed in the 'master' branch,
but were unable to switch due to large amount of changes since the previous
release. Because of that, I think that a change of the release process is
needed. There are still many roles that need to be cleaned up and rewritten,
but hopefully a stable branch that will get bugfixes over time will be useful
to the users that require a bit more predictability.
The stable branch, first one named 'stable-1.0', will get bugfixes and security
fixes as long as the code in the 'master' branch is compatible, but there will
be no new features or major changes in the existing roles. If a role in the
'master' branch has been modified too much and direct cherry-picking of the
changes is impossible, the bugfixes might go directly to the stable branch, but
at this point a given release will probably become unsupported when a few more
recent releases are available.
DebOps uses the Semantic Versioning for its releases, with major.minor.patch
numbers. Depending on the changes, major release bump might happen on the next
release, but it's hard to tell what changes might require this. Most likely
large modifications to the Ansible inventory or changes on the remote hosts
that require a host rebuild from scratch will result in major version bump,
less severe changes will have a minor version bump.
The release schedule from the 'master' branch will probably stay the same - a
few months between each release, so that features can be polished and any bugs
fixed beforehand. Updates to the stable branches will be quickier though,
depending on bugfixes.
Plans for the next release
The release of Debian Buster draws closer, and I would like to prepare DebOps
for it beforehand. A migration or possible rewrite of the AppArmor role will
need to happen soon, also the 'debops.ipxe' and 'debops.preseed' roles need to
be updated to support installation of Buster via preseeding.
Various application roles will be updated to use the new 'debops.ldap' role to
manage LDAP entries and access to the directory. I would also like to include
support for Samba and Heimdal Kerberos to reap the benefits of the
'slapd-smbk5pwd' module that allows password synchronization between various
LDAP objects. This should also benefit NFS support which could finally be
properly secured via Kerberos.
Support for installing Golang applications from source will be implemented as
well, compilation will be done on a separate unprivileged account. And as
usual, new applications, rewrites of the old roles and bugfixes here and there.
Thanks for reading and see you out there.
Hello DebOps community,
I start using DebOps project since few days and I would like to get
involved in DebOps project. I'm reading the mailing-list since 4 months.
My idea is to start by improving DebOps documentation because I'm a
documentation fanatic :-)
Also, I would like to know if plans to using a tool like Testinfra are
still here. I ask this question because I'm currently working on this
subject and I would be interested to contribute on that part.
Jabber/XMPP : nqb(a)azyx.fr