Heads up, I've pushed the below. As noted below, this will trigger an upgrade of the base domain (but only once).
commit 093a9d912ec6a56602d2813196fc3d14444cd871 (HEAD -> master, origin/master, origin/HEAD) Author: Andrew Cagney <[email protected]> Date: Wed Jan 23 14:02:36 2019 -0500 kvm: merge base and clone domains, make base domain per-build tree The domains are reduced to: [prefix]swan${OS}base -> [prefix]nic -> [prefix]build -> {prefixes}{east,west,...} There's one quirk, base is built in two steps using two make rules: 1. build the base domain 2. upgrade the base domain (new) and the second may trigger a rebuild of most domains On Mon, 21 Jan 2019 at 12:53, Andrew Cagney <[email protected]> wrote: > > Picking up an offline discussion. > > Long ago the domain structure looked like: > > base - the initial OS install > east,west,nic,... cloned from base > > it had several problems: > > - rebuilding base was exceptionally unreliable, network intensive, and > failures were non-obvious > - only one OS was allowed > - only one test directory was allowed > - it wasn't parallel > - installing was slow > > but things have evolved: > > - building a per-OS base is done in three clear steps - download the > ISO, install the ISO, upgrade the OS - and that along with KVM/kernel > fixes have made the process far more reliable > - a per-os base is allowed > - multiple build directories are allowed > - parallel testing is allowed > - installs were sped up by adding a dedicated build machine that could be > cloned > > and the structure looks something like: > > OS base (shared) > clone - local to build tree > nic* - disk cloned from clone > build* - disk cloned from clone > east,west,north,south* - disk cloned from build > > (* denotes a domain that can be moved to /tmp) however, as this > evolved some quirks were picked up, the notable one is the clone > domain which sits between the base domain and the test domains. It's > purpose was: > > - isolate the build domains from the base domain (if the base domain > was deleted things didn't barf) > - provide somewhere to prototype changes (a clean starting point could > be created by re-creating clone from base) > > Two changes were put forward, but they are somewhat contradictory: > > - merge clone and base creating a per-build tree base domain - for > most developers clone adds no benefit > - keep clone and allow it to be created in /tmp - but I'm not sure > this is a benefit though as, during testing, all the useful contents > of clone's disk should end up, read-only, in the buffer/cache which is > faster again then /tmp > > with this in mind I'm planning on implementing the first suggestion - > merge base and clone. > > Andrew _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
