ipng/lab
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update README to reflect latest state

Browse Source
This commit is contained in:
Pim van Pelt
2022-10-19 14:18:38 +02:00
parent 9e22d00c0f
commit 01631ead29
1 changed files with 47 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
README.md
View File

@ -19,18 +19,15 @@ The main `vpp-proto` image runs on `hvn0.chbtl0.ipng.ch` with a VM called `vpp-p
When you want to refresh the image, you can When you want to refresh the image, you can
``` ```
spongebob:~$ ssh -A root@hvn0.chbtl0.ipng.ch hvn0-chbtl0:~$ virsh start --console vpp-proto
SNAP=$(date +%Y%m%d) ## 20221012
zfs snapshot ssd-vol0/vpp-proto-disk0@${SNAP}-before
virsh start --console vpp-proto
## Do the upgrades, make changes to vpp-proto's disk image ## Do the upgrades, make changes to vpp-proto's disk image
## You can always roll back to the -before image if you'd like to revert ## You can always roll back to the previous snapshot image if you'd like to revert
virsh shutdown --console vpp-proto hvn0-chbtl0:~$ SNAP=$(date +%Y%m%d) ## 20221012
zfs snapshot ssd-vol0/vpp-proto-disk0@${SNAP}-release hvn0-chbtl0:~$ virsh shutdown --console vpp-proto
zrepl signal wakeup vpp-proto-snapshots hvn0-chbtl0:~$ sudo zfs snapshot ssd-vol0/vpp-proto-disk0@${SNAP}-release
hvn0-chbtl0:~$ sudo zrepl signal wakeup vpp-proto-snapshots
``` ```
There is a `zrepl` running on this machine, which can pick up the snapshot by manually There is a `zrepl` running on this machine, which can pick up the snapshot by manually
@ -41,7 +38,7 @@ running labs will not be disrupted, as they will be cloned off of old snapshots.
You will find the image as `ssd-vol0/hvn0.chbtl0.ipng.ch/ssd-vol0/vpp-proto-disk0`: You will find the image as `ssd-vol0/hvn0.chbtl0.ipng.ch/ssd-vol0/vpp-proto-disk0`:
``` ```
spongebob:~$ ssh -A root@hvn0.lab.ipng.ch 'zfs list -t snap' lab:~$ ssh -A root@hvn0.lab.ipng.ch 'zfs list -t snap'
NAME USED AVAIL REFER MOUNTPOINT NAME USED AVAIL REFER MOUNTPOINT
ssd-vol0/hvn0.chbtl0.ipng.ch/ssd-vol0/vpp-proto-disk0@20221013-release 0B - 6.04G - ssd-vol0/hvn0.chbtl0.ipng.ch/ssd-vol0/vpp-proto-disk0@20221013-release 0B - 6.04G -
``` ```
@ -65,15 +62,17 @@ SSH keys, Bird/FRR configs, etc). We do this on the lab controller `lab.ipng.ch`
1. Rsync's the built overlay into that filesystem 1. Rsync's the built overlay into that filesystem
1. Unmounts the filesystem 1. Unmounts the filesystem
1. Starts the VM using the newly built filesystem 1. Starts the VM using the newly built filesystem
1. Commits the `openvswitch` topology configuration (see `overlays/*/ovs-config.sh`)
Of course, the first two steps are meant to ensure we don't clobber running labs, which can Of course, the first two steps are meant to ensure we don't clobber running labs, which can
be overridden with the `--force` flag. And when the lab is finished, it's common practice to be overridden with the `--force` flag. And when the lab is finished, it's common practice to
shut down the VMs and destroy the clones. shut down the VMs and destroy the clones.
``` ```
lab:~/src/ipng-lab$ ./destroy --host hvn0.lab.ipng.ch lab:~/src/lab$ ./generate --host hvn0.lab.ipng.ch --overlay default
lab:~/src/ipng-lab$ ./generate --host hvn0.lab.ipng.ch --overlay bird lab:~/src/lab$ lab=0 ./destroy ## remove VMs and ZFS clones
lab:~/src/ipng-lab$ ./create --host hvn0.lab.ipng.ch --overlay bird lab:~/src/lab$ lab=0 ./create ## create ZFS 'pristine' snapshot and start VMs
lab:~/src/lab$ lab=0 ./pristine ## return the lab to the latest 'pristine' snapshot
``` ```
### Generate ### Generate
@ -81,22 +80,48 @@ lab:~/src/ipng-lab$ ./create --host hvn0.lab.ipng.ch --overlay bird
The generator reads input YAML files one after another merging and overriding them as it goes along, The generator reads input YAML files one after another merging and overriding them as it goes along,
then for each node building a `node` dictionary alongside the `lab` and other information from the then for each node building a `node` dictionary alongside the `lab` and other information from the
config files. Then, it read the `overlays` dictionary for a given --overlay type, reading all the config files. Then, it read the `overlays` dictionary for a given --overlay type, reading all the
template files from that overlay directory and assembling an output directory which will hold the common files from that overlay directory and assembling an output directory which will hold the
per-node overrides, emitting them to the directory specified by the --build flag. It also copies in per-node overrides, emitting them to the directory specified by the --build flag. It also copies in
any per-node files (if they exist) from the overlays/$(overlay)/blobs/$(node.hostname)/ giving full any per-node files (if they exist) from the overlays/$(overlay)/hostname/$(node.hostname)/ giving full
control of the filesystem's contents. control of the filesystem's ultimate contents.
```
lab:~/src/lab$ ./generate --host hvn0.lab.ipng.ch --overlay default
lab:~/src/lab$ git status build/default/hvn0.lab.ipng.ch/
```
### Destroy
Ensures that both the VMs are not running (and will stop them if they are), and their filesystem
clones are destroyed. Obviously this is the most dangerous operation of the bunch, but the philosophy
of the lab is that the VMs can be re-created off of a stable base image and a generated build.
```
lab:~/src/lab$ lab=0 ./destroy ## remove VMs and ZFS clones on hvn0.lab.ipng.ch
```
### Create ### Create
Based on a generated directory and a lab YAML description, uses SSH to connect to the hypervisor, Based on a generated directory and a lab YAML description, uses SSH to connect to the hypervisor,
create a clone of the base `vpp-proto` snapshot, mount it locally in a staging directory, then rsync create a clone of the base `vpp-proto` snapshot, mount it locally in a staging directory, then rsync
over the generated overlay from files from the generator output (build/$(overlay)/$(node.hostname)) over the generated overlay from files from the generator output (build/$(overlay)/$(node.hostname))
after which the directory is unmounted and the virtual machine booted from the clone. after which the directory is unmounted and a specific ZFS snapshot is created called `pristine`.
The VMs are booted off of their `pristine` snapshot.
If the VM is running, or there exists a clone, an error is printed and the process skips over that Typically, it's necessary to destroy/create, only when the build or the base image change. Otherwise,
node. It's wise to run `destroy` before `create` to ensure the hypervisors are in a pristine state. the lab can be brought back into a _factory default_ state by rolling back to the `pristine` snapshot.
### Destroy ```
lab:~/src/lab$ lab=0 ./create ## create ZFS 'pristine' snapshots and start VMs
```
Ensures that both the VMs are not running (and will stop them if they are), and their filesystem ### Pristine
clones are destroyed. Obviously this is the most dangerous operation of the bunch.
In the process of creating the ZFS clones and their per-node filesystems, a snapshot of each VM's
boot disk is made, and this is called the `pristine` snapshot. After using the lab, it can be quickly
brought back into a default state by rolling back the disks to the `pristine` snapshot and restarting
the virtual machines.
```
lab:~/src/lab$ lab=0 ./pristine ## return the lab to the latest 'pristine' snapshot
```