diff options
author | Lars Wirzenius <liw@liw.fi> | 2020-03-01 20:21:12 +0200 |
---|---|---|
committer | Lars Wirzenius <liw@liw.fi> | 2020-03-01 20:21:12 +0200 |
commit | 22014c158a282b9679797c847229cbf345c39622 (patch) | |
tree | 7ed0ed0178b1c0f3a06399d8d170f7aab17da49e /contractor.md | |
parent | 525a8f69ec31e158fe4a4ab5dbfbe5ffba8c75ee (diff) | |
download | ick-contractor-22014c158a282b9679797c847229cbf345c39622.tar.gz |
Change: start sketch for implementation
Diffstat (limited to 'contractor.md')
-rw-r--r-- | contractor.md | 23 |
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 |