labhost

Overview ¶

labhost はラボの VM の中でシナリオを流す道具 (試作)。VM は OS とカーネルを与える Lab Host で、 テストを隔てる単位は VM ではなく Sandbox である、という筋書きを確かめるために作った。 1 つの Sandbox は ID、5 つの network namespace、作業ディレクトリ、そして自分が起こした プロセスを持つ。シナリオ自身は lab/*.sh のまま動かし、Sandbox の値を環境変数で渡す。

labhost run -parallel 4 -repeat 8 "e2e.sh kernel"
labhost run -parallel 4 "e2e.sh kernel" "ipv6.sh kernel"
labhost gc
labhost list

VM の中で root として実行する。ホストでのビルドと VM への導入は lab/lab build が行う。

proc_unix.go は labhost がプロセスを所有するための Unix 依存の部分。labhost が動くのは ラボの VM (Linux) だけだが、リポジトリは Windows と macOS 向けにもビルドできる必要があるので、 syscall に触る部分をこのファイルに閉じ込める。

runlock.go は 1 台の Lab Host VM の中で `labhost run` を 1 つに限るロック。

なぜ VM ごとに 1 つかというと、`exclusive-heavy` と `exclusive-timing` の分類が約束するのは 「Lab Host VM の中で単独で流す」ことだからである。2 つの run は互いの日程を知らないので、 一方の単独の仕事が他方のどの仕事とでも重なりうる。ロックを -root の下に置くと、別の -root を 指した 2 つの run が同時に走れてしまい、約束が崩れる。RSS と到達頻度の測定は VM 全体の資源に 左右されるので、名前空間が衝突しない組み合わせであっても同時には流せない。

gc も同じロックを取る。gc の走査は prefix だけを頼りにするので、同じ prefix で別の -root を 使う run が居ると、gc はその run の生きている Sandbox の作業ディレクトリのロック (別の root の下にある) を見つけられず、生きている netns を消してしまう。VM ごとのロックは この穴も塞ぐ。

ロックの実体は internal/flock、つまりカーネルが持つ flock である。持ち主のプロセスが死ねば (SIGKILL でも) カーネルが解放するので、PID ファイルのように残らない。ロックファイルの中身には 持ち主の PID を書くが、それは断るときの案内に使うだけで、判定には使わない。

sandbox.go は Sandbox の一生を扱う。Sandbox は 5 つの network namespace、作業ディレクトリ、 そして自分が起こしたプロセスだけを持ち、他の Sandbox と VM 全体には触らない。

suite.go は lab/suite.txt の読み取りと、2 つの分類だけを持つ日程の組み立て。 並列に流せる仕事はプールで同時に流し、単独で流す仕事は 1 つずつ流す。 メモリを見て加減する仕組みは持たない。