summaryrefslogtreecommitdiff
path: root/contractor.md
diff options
context:
space:
mode:
authorLars Wirzenius <liw@liw.fi>2020-03-01 20:21:12 +0200
committerLars Wirzenius <liw@liw.fi>2020-03-01 20:21:12 +0200
commit22014c158a282b9679797c847229cbf345c39622 (patch)
tree7ed0ed0178b1c0f3a06399d8d170f7aab17da49e /contractor.md
parent525a8f69ec31e158fe4a4ab5dbfbe5ffba8c75ee (diff)
downloadick-contractor-22014c158a282b9679797c847229cbf345c39622.tar.gz
Change: start sketch for implementation
Diffstat (limited to 'contractor.md')
-rw-r--r--contractor.md23
1 files changed, 22 insertions, 1 deletions
diff --git a/contractor.md b/contractor.md
index f5bc869..d960a7b 100644
--- a/contractor.md
+++ b/contractor.md
@@ -9,6 +9,11 @@ author: "Lars Wirzenius"
This document is in its very early stages, as is the whole Contractor
project.
+## Open questions
+
+* How should the command line tool communicate with the manager
+ processes in the outer VM?
+
# Introduction
A continuous integration engine (CI) takes the source code for a
@@ -158,7 +163,10 @@ This high-level design is chosen for the following reasons:
* it allows the build to happen in any operating system
(**AnyBuildOS**)
* the Contractor is a VM and running it doesn't require root
- privileges; it has root inside the VM if needed (**NoRoot**)
+ privileges; it has root inside the VM if needed; all the complexity
+ of setting things up so the builder VM works correctly are contained
+ the outer VM, and the user need do only minimal configuration
+ (**NoRoot**)
* the command line tool for using the Contractor can be made to be as
easy as any build tool so that developer actually use it by default
(**DefaultBuilder**)
@@ -197,6 +205,19 @@ The architecture leads to a build process that would work like this:
* command line tool reports to the developer build success or failure
and where build log and build artifacts are
+## Implementation sketch
+
+The outer VM runs Debian stable, and has libvirt to run guest VMs. The
+host and the outer VM are configured to support nested VMs, if the
+host hardware supports it. The outer VM has its networking configured
+so that it can connect to hosts outside itself, but the inner VM can
+only connect to services inside the outer VM. The services provided to
+the inner VM are an artifact store, and an HTTP proxy. (That's the
+only protocol I know of right now; more can be added if need be.)
+
+The artifact store is mounted to the outer VM using 9p. A web service
+in the outer VM serves the files to the inner VM. The developer can
+access the artifact store via their local file system.
# Acceptance criteria