libvirt_cloud/README.md

Spin up libvrt instances from a cloud-init capable base that can be
maintained using chroot on qcow2, and by ansible using libvirt_qemu.

This builds on two projects:
1) bash scripts to take a Gentoo qcow2 nightly box and use it as a base layer
for another qcow image that you spin up in libvirt, overlaying the base layer
for testing. You can then throw away that image for each test (if you like);
it takes less than a minute to make the base qcow2 layer, and other minute
to make the overlay layer and spin it up.
https://github.com/earlruby/create-vm/

2) python scripts to take a Gentoo stage3 and portage to build a qcow2 box and
use it as a base layer for a cloud-init capable qcow image.
https://github.com/NucleaPeon/gentooimgr/

The huge advantage of this is that you can maintain the base image
under chroot, so you can build test instances that have no incoming
network and still maintain them using tools like ansible, which
support maintaing chroot instances. The problem of using 1) gentooimgr
is that the configuration code of the install step is written in
Python, rather than handled by a more capable tool like ansible.

The problem of using 2) gentooimgr is that the base box may be old (it
is) and you may want to use an existing gentoo kernel and initramfs,
and the base box may be missing qemu-quest-agent (it is). *Much* worse
is that to use cloud-init you have to load rust and 344 crates from
God only knows where that you'll never audit, just to get oauth: no
thanks Google.

You can use ansible to maintain the base layer using chroot, and use
it again to create and spin up the test instance. And as we install
qemu-quest-agent in the base layer, you can manage the test instance
with ansible using libvirt guest-agent, even if the test instance
allows no incoming network.

For now, the code is written to build Gentoo base images, but it could
be extended to other bases. It can build a Gentoo base image from a
Gentoo system.  or another system with a Gentoo system mounted on some
directory, that can be chrooted into, and files copied from. It may be
able to build from a Debian without a mounted Gentoo filesystem, but this
is currently untested.

## Workflow

1) We build the qcow2 base image that we can maintain by chroot
mounting the disk, so we can sort out problems conveniently. We started
doing that by using EarlRuby's python approach, but later rewrote an
old ansible role by https://github.com/agaffney/ansible-gentoo_install/
That ansible role is in roles/ansible-gentoo_install/tasks/ which is
executed as an included role by the toxcore role.

It's a very basic piece of coding that works on a local connection
and is run on the host by the build_base Makefile target. It starts
out as a local connection play, and run chroot internally when it needs it.
You must set these variable in a host in hosts.yml in the linux_chroot_group:
          BOX_NBD_DEV: nbd1
          BOX_NBD_MP: /mnt/gentoo
          BOX_NBD_FILES: "/i/data/Agile/tmp/Topics/GentooImgr"
          BOX_NBD_BASE_QCOW: "/g/Agile/tmp/Topics/GentooImgr/gentoo.qcow2"
This role is slow and may take an hour or more;
It will build the BOX_NBD_BASE_QCOW.

As a safety feature you must create and open the qcow base image before
running the roles: the roles do not use qemu-nbd -c or qemu-nbd -d by
design. You may also choose to download the gentoo latest stage3 and
portage files to the directory specified in hosts.ynl as BOX_NBD_FILES
These

2) We build the qcow2 overlay image that we can maintain by libvirt.
It is run on the host by the build_overlay Makefile target which runs
/usr/local/bin/toxcore_build_overlay_qcow.bash. It gets its parameters from
the hosts.yml file from the host called gentoo1 in the linux_libvirt_group.

## Roles

There are 3 ansible roles:

1. base : The base role sets up the basics and is required to be run.

2. proxy : The proxy role sets up the networking with proxies,
   and is required to be run, even if you don't use a proxy.

3. toxcore : 

Each role has been conditionalized to run with different connections.
 
## Connection Types

There are 3 ansible connection types:

1. localhost : ( ansible_connection == local )
   Running the roles with a local connection will setup the host to
   be able to run the software. The toxcore role will build the
   toxcore software on the localhost and runs tests on it. It will also
   build the base qcow2 image that will underly the overlay box.
   
2. chroot : ( ansible_connection == chroot )
   When you have built the base box, you can chroot mount the qcow2 image
   with qemu-nbd, so all of the configuring of the base can be done without
   a network. A local bash script then builds the overlay qcow2 instance,
   in less than a minute.
   
3. remote :  ( ansible_connection == libvirt_qemu )
   The base box provides the libvirt_qemu connection that is be used
   to run ansible roles on the overlay image. The toxcore role will
   build the toxcore software in the overlay and runs tests on it.
   
All of the 3 roles can all be run with all 3 connection types.

## Stages

There are 4 stages to building an instance:

1. Setup the localhost : 
   set up the host up with the software and settings needed to build boxes.
   
2. Build the base qcow2 base box :
   
3. Build the overlay qcow2 instance : 

4. Test the overlay instance :

## Hosts.yml targets

## Makefile targets

all: install lint build check run test

1. install

2. lint

3. build

4. check

5. run

6. test

## Simplest usage

On Ansibles from 2.10 and later, you will need the community plugins installed.

### Downloaded base qcow

### Created and copuied base qcow on a Gentoo system

### Created and copied base qcow on a non-Gentoo system with a Gentoo mounted

## Advanced Usage

### ansible_local.bash

We have a script that calls ansible to run our play: ansible_local.yml

[ -l limit ]
[ -c connection ]
[ --skip comma,separated]
[ --tags comma,separated]
[ --check]
[ --diff]
[ --step]
[ --verbose 0-3] higher number, more debugging
roles - base and proxy roles will always be run.