[Reproducible-commits] [blog] 01/01: Discuss changing the backend

[Ceridwen]

This is an automated email from the git hooks/post-receive script.

ceridwen-guest pushed a commit to branch master
in repository blog.

commit f677d13431c661754b170ba7dd271b0b5ac252b0
Author: Ceridwen <ceridwenv at gmail.com>
Date:   Thu Aug 11 17:55:18 2016 -0400

    Discuss changing the backend
---
 drafts/people/ceridwen/reprotest_week11.mdwn | 99 ++++++++++++++++++++++++++++
 1 file changed, 99 insertions(+)

diff --git a/drafts/people/ceridwen/reprotest_week11.mdwn b/drafts/people/ceridwen/reprotest_week11.mdwn
new file mode 100644
index 0000000..dfe126d
--- /dev/null
+++ b/drafts/people/ceridwen/reprotest_week11.mdwn
@@ -0,0 +1,99 @@
+[[!meta title="New problems and discussions of alternative approaches for reprotest"]]
+[[!meta date=""]]
+[[!tag reproducible_builds Debian reprotest Outreachy]]
+Author: ceridwen
+
+In working out user-group for reprotest, I've hit a new problem.  The
+general form of the shell scripts that reprotest generates at the
+moment look like `(setup && build_command) || cleanup`, where setup
+includes commands that have to be run before the build command and
+cleanup includes code that has to be executed to reset the build
+environment to its original state.  However, I didn't realize before
+that if there's a failure in the first run and the cleanup code is
+executed, the script exits using the cleanup code's exit value, which
+is not error if the cleanup is working correctly.  Thus, this isn't
+handling a build failure correctly.
+
+Thanks to deki, I think I know how to fix this, but the fix gets ugly.
+
+    (setup && build_command);
+    exit_code = $?;
+    if test $exit_code -ne 0;
+    then cleanup;
+    fi
+    exit $?
+
+However, this doesn't handle stderr redirection, which is also needed:
+the exit code stderr from the setup and build command need to be used
+as the values for the whole script if the setup or build command
+fails.  If the build command succeeds and there's a failure in the
+cleanup, its exit code and stderr needs to be used as the output of
+the script.
+
+More generally, though, I'm concerned about how much of the code is
+now generated shell code rather than Python.  Part of my concern is
+debugging, but I'm also wondering how comprehensible this is going to
+be to anyone who isn't me.  The generated shell scripts are hitting
+the level of complexity where I would want to move them into a real
+programming language.  However, because of autopkgtest's design,
+there's no way to write cleanup code in Python, no matter how
+complicated it gets.
+
+One possible solution to this problem is to change the autopkgtest
+code to make it possible to pass Python code that will then be used in
+cleanup.  The major obstacle is autopkgtest's division into an inner
+and outer Python process.  Since the inner process is a separate
+interpreter, I'd be looking at the kinds of tricks that people use to
+pass code between processes like pickling code and then having the
+inner process execute it.  This would be complicated and I'm not sure
+how much easier it would be to understand and debug than shell
+scripts.  It would also require modifying `VirtSubproc.py` so that
+when it exits, it runs said code.  Alternately, I could make it so
+that the many conditions that currently cause `VirtSubproc.py` to
+terminate no longer do so, holding it open so that the code in
+`adt_testbed.py` can run the cleanup code.  Of course, there's some
+risk that this could put the build environment into some sort of
+inconsistent state.
+
+Thus, I've been looking at more radical solutions.  I've been reading
+the [Ansible](https://docs.ansible.com/)
+[modules](https://github.com/ansible/ansible-modules-core) code to
+figure out how they're implementing some of the things I also have to
+do, like creating users and groups.  However, Ansible supports
+chroots, qemu, and other forms of virtualization, which means that it
+could replace autopkgtest.  This sounds insane and maybe is insane,
+but let me make the case for it.  Ansible would have three big
+advantages.  The first is that I think I could use Ansible without
+having to import and modify the code like I have done with
+autopkgtest, which would decrease the number of tests I still have to
+write and the amount of code that I have to audit and (in some cases)
+delete.  The second is that Ansible contains portable implementations
+that already do the error handling and cleanup I need for some of the
+variations, which would save me some coding trying to get that to
+work.  The third is that it's possible to write new modules for
+Ansible in Python rather than shell.  The move sounds more radical
+than it is, because reprotest's code is separate from the autopkgtest
+code and much of the existing reprotest code could be converted
+mechanically to use Ansible.  Ansible uses YAML to describe systems,
+and reprotest could generate YAML instead of shell scripts.  There are
+also some notable disadvantages.  Ansible has a bigger footprint than
+autopkgtest, because rather than running commands like autopkgtest
+does, Ansible requires that the build environment have access to a
+Python interpreter and Ansible itself; this is how it
+avoids having to have most of the code written in shell.  Another
+problem is that I don't know immediately how I'd get "build on the
+host system" working, though there's always the `ssh localhost`
+workaround.
+
+While looking at Ansible, I also did a little looking at some
+alternatives.  [Salt](https://docs.saltstack.com/en/latest/topics/)
+has a similar purpose as Ansible and is also written in Python with
+modules for doing specific tasks.  In a brief look, though, I couldn't
+find a straightforward indication you can use Salt to run things like
+chroots and qemu.  There are other tools in other languages, but I
+don't see that they would have any advantages.  There's also
+[libvirt](https://libvirt.org/index.html), which is what Ansible uses
+to control some build environments (Linux containers, Qemu), but as
+far as I know it doesn't handle chroot out of the box, is lower-level
+with a kind of awkward API though it does have
+[Python bindings](https://libvirt.org/python.html).

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/blog.git