[Swan-dev] merging base and clone test domains

[Andrew Cagney]

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 <cagney at gnu.org>
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 <andrew.cagney at gmail.com> 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